Find your way
with Obsyrix.

Your organization’s Obsyrix workspace is separate from this public website. Use the address and named account supplied by your administrator. The screens you can use depend on your role and the modules enabled for that deployment.

1. Open your workspace and sign in. If you do not have an address or account, ask your deployment administrator. This Knowledge Base and the public model explorer do not sign you into an installed workspace.
2. Start with Situation. Review the available attention items and measurement timestamps. An empty or partial view is a reason to check the data source, rather than assume everything is healthy.
3. Find an asset in TERMYX. The directory contains registered devices and their configured ways to connect. Viewing an asset and opening a remote session are separate permissions.
4. Follow work in DESK. Open an existing ticket to see its owner, group, location and activity. Use COMMS to coordinate with colleagues where that service is available.

Next: add a device or understand measurement freshness.

A directory entry describes an asset. It does not, by itself, establish a successful connection or turn on every type of monitoring.

1. Open the TERMYX directory. If your account can edit devices, choose + Add Device.
2. Choose the appropriate category and subcategory. Classification describes the asset; it does not determine its connection method.
3. Under Connection, configure the approved network address and mode, or the configured serial-line details. Check the address and port against your device record.
4. Record the location and other identifying details your team needs. Save the device, then find it again in the directory.
5. Have the relevant administrator configure monitoring credentials, collector scope and session permissions. Verify each capability separately.

More than one access method?

A device can have additional configured access methods, such as a different SSH address or a web interface. Choose the registered method that matches the task. Remote sessions require their own authorization.

Checks answer a narrow question: does a web page respond as expected, does a TCP port accept a connection, or does a name resolve? They run from the Obsyrix server, so a result can differ from what your laptop sees.

1. An administrator opens Integrations → Checks and chooses Add a check.
2. Give the check a useful name and select its kind. Enter a web address for HTTP, a host and port for TCP, or a name for DNS.
3. Set the expected result. HTTP can match a status or range and an optional word or phrase. DNS can require an expected address. TCP tests whether the connection opens.
4. Set the interval, timeout, consecutive misses before failure and severity. Optionally associate the check with a registered device.
5. Use Test to try the current form. This sends a real check from the server. Save the check when its target and expectation are correct.
6. Review its state and History. Run now requests a new result for a saved check.

A check becomes failing after the configured number of misses. A passing result clears that failure. Alert delivery also depends on configured channels; an HTTP success does not prove the whole application is working.

Keep HTTP certificate verification enabled. If a certificate check fails, ask the service owner to investigate the certificate or trust configuration.

SNMP polling and SNMP traps provide different observations. A collector requests measurements from a device; a trap receiver accepts events sent by a device.

Before expecting measurements

• Confirm that the deployed collector has a suitable device profile. Current metric profiles cover Ruggedcom ROS, MikroTik RouterOS, net-snmp Linux, HP/Aruba ProCurve and Juniper Junos. An SNMP-capable device does not automatically expose the same measurements.
• Ask your administrator to configure the correct SNMPv2c or SNMPv3 credentials and device/category/default binding for the intended target.
• Confirm the approved network route and device access policy allow the Obsyrix services to reach it. A no-response error can mean reachability, disabled SNMP or incorrect credentials; it is not a certain offline diagnosis.
• Check the latest sample time and source in the application. Available values depend on the device profile and reported observations.

For traps

The device must send events to the configured receiver. In Live Monitor, trap rules can raise problems and, when configured, create linked DESK tickets. A trap event and a fresh polling sample are separate facts.

For interpretation, see fresh, stale and missing measurements.

A displayed value is useful only with its source and sample time. Refreshing a screen is different from collecting a new equipment measurement.

• Fresh: the sample fits the application’s age policy for its recognized source. This describes that sample; it is not a guarantee that every service is healthy.
• Stale: a previously reported value is older than its source’s threshold. Treat it as a last reported observation.
• Unavailable or missing: there is no usable measurement for that field. Missing values do not become zero.
• Partial: some sources or observations are unavailable. Review the available findings without treating the whole environment as all clear.

Temperature and host cards

Situation includes a Device temperatures view and supports up to six pinned host cards. A card can show the device, source, CPU, memory, hottest reported sensor, uptime and measurement time when those observations exist.

Zero and negative finite temperatures can be valid measurements. No reported temperature does not, on its own, prove that the hardware lacks a sensor. There is no universal temperature threshold for every device.

If data is unexpectedly old or missing, follow the missing-data checklist.

The public site and model explorer is an interactive illustration. It uses fictional training environments and needs no workspace account.

1. Choose an industry. The examples cover rail, water, utilities, manufacturing, renewables, ISPs, data centers, enterprise offices, fleet depots and medical facilities.
2. Start with the site map. Select an asset to see its identity and placement, then open the model to inspect its surroundings.
3. Rotate and zoom the 3D view. Select modeled equipment to see its details and configured relationships.
4. Use the available network, roof and floor controls to adjust the view. Medical examples include one-, two- and five-floor variants.
5. Try the labeled training incident and restore the training scenario when finished. This changes the local illustration; it sends no commands to equipment.

Using your own site in Obsyrix

In an installed workspace, TERRAIN uses configured sites, buildings, floors, rooms, device placements and available model data. Your administrator must configure the relevant site and inventory. The public examples do not create those records in your deployment.

The 3D explorer requires WebGL 2. If it cannot render, try a supported browser with graphics acceleration available, or continue reading the guides.

A model explains where equipment belongs and how configured relationships fit together. Its appearance does not establish a physical installation, a live feed or an equipment capability.

• Public explorer: original schematic geometry, fictional equipment and explicitly labeled fixed example values or training incidents. No live equipment is connected.
• Native workspace: configured site geometry and inventory can provide context for device selection. Operational readings depend on separately configured collectors and current observations.
• Relationship overlay: a modeled network, power or process relationship describes the fixture or configured context. It does not prove current traffic flow or operate that relationship.
• Absent measurement: no sample means no reading. A model selection does not manufacture a value.

Use measurement timestamps and source status to evaluate actual observations in your workspace.

Remote access starts with a registered device and an approved connection method. Being able to see inventory does not automatically authorize a remote session.

1. Find the device in the TERMYX directory and confirm its identity, configured address and port.
2. Choose the registered connection or additional access method that matches your task. Industrial protocol labels in inventory do not open a terminal.
3. Confirm that your account is authorized for that device and protocol. If access is denied, ask the administrator to review the permission.
4. For SSH, the exact endpoint must have an independently verified public host key enrolled by an administrator. See SSH host key trust.
5. Use the requested device credentials through your approved workflow. Close the session when the task is finished; hiding the terminal panel does not close its sessions.

Physical serial connections

Physical serial access on the Obsyrix server is restricted to administrator/developer accounts and the configured serial port. One session holds a serial line at a time. If the port is busy, coordinate with the person using it rather than opening competing sessions.

Identify the failing stage

Network reachability, device/protocol permission, SSH host identity and device authentication are separate checks. Record the precise error and stage before changing configuration.

Obsyrix SSH trust applies to the exact registered device, host and TCP port. A trusted key on port 22 does not authorize a different port or device. Unknown or changed keys prevent the connection.

1. An administrator obtains the device’s OpenSSH public host key from a trusted console, controlled provisioning record or another independently authenticated source.
2. Independently verify its SHA-256 fingerprint. A user’s login key is different from the device’s host key. Never enter a private key in the host-key field.
3. Open Integrations → SSH trust and select the registered endpoint.
4. Enter the public host key and choose Show key fingerprint. Compare it with the independent source, confirm the comparison and record the verification source.
5. Choose Enroll verified key, then retry the approved session. Enrollment stores the verified identity; it does not contact the device.

If a previously trusted key changes

Stop and verify the reason independently with the device owner. A legitimate rotation still needs a verified replacement. Do not treat the key returned by a failed connection as sufficient evidence to trust it.

After a successful database restore, SSH enrollments are cleared and require independent verification and re-enrollment. Ask the administrator to review trust before retrying affected sessions or configuration backups.

1. Read the exact state. Note whether the screen says missing, stale, unavailable, partial, waiting or failing. Save the error text and its timestamp.
2. Check the sample time and source. A current page refresh is not a new measurement. Confirm that you are looking at the intended device and collector source.
3. Check scope and configuration. Ask the administrator whether the collector, optional service, credentials and target are configured for this deployment.
4. Distinguish empty from unavailable. Zero stored PULSE observations is different from unavailable storage or a failed read. Stored observations also do not prove the scanner is currently running or that an application protocol answers.
5. Retry the view when appropriate. If the error persists, collect the details below for your administrator or support. A failed API request does not by itself establish that a device is offline.

If a browser view fails, note the browser, affected screen, time and error. If a configured check fails, inspect its last result and history from the server’s point of view. Prepare a support request with those details.

An SNMP problem or a configured check can recover while the related DESK ticket remains open. Recovery describes the observed signal. Ticket resolution records the team’s decision and work.

1. Review the latest alert or check result and confirm what recovered.
2. Open the linked DESK ticket and check the affected device, group, assignee and activity.
3. Coordinate findings in COMMS where available. Share the incident context so colleagues can follow the same investigation.
4. Once the team has verified the result, the authorized operator records the findings and resolves the ticket through the normal DESK workflow.

A ticket history is useful context for the next operator. Do not assume an alert clearing means that all investigation or follow-up is complete.

Contact [email protected]. For account access, device permissions or deployment-specific configuration, your organization’s administrator is also a useful first contact.

Include these details

• The affected Obsyrix screen or workflow and the deployment name your team uses.
• What you expected, what happened and the steps that reproduce it.
• The exact error text, time and time zone. Include the displayed version if it is available.
• Your browser and whether the issue affects one person, one device or a wider set.
• Relevant sample/source timestamps or check history, and a screenshot with sensitive information removed.

Do not email passwords, private keys, SNMP secrets, tokens or complete credential exports. Share only the device and network details needed to explain the issue, using your organization’s approved process.