Device reads and monitoring

Start with the device and its evidence

Monitoring reads enrolled devices at their recorded management addresses. Discovery establishes an identity; monitoring revisits it to collect the information that device and its access method support. A device answering does not mean every port, neighbour, stack member, or power supply was read successfully.

Open Monitoring to review SSH, SNMPv3, ports and endpoints, and site collectors. Then open the device for its individual evidence and observation times. Use the summary to find a problem, but use the affected reading to decide what happened. An old successful reading remains useful history; it is not a fresh health check.

Prepare credentials and trust

Give the device account the access needed for the supported read commands and tables. A successful sign-in can still leave individual commands unavailable. After rotating a credential, check that the intended collector has the current version of the credential before treating a missing collector read as a device fault.

Publishing an approved SNMP read list does not authorize collector reads. Activating that exact list authorizes only eligible collectors that have the same list installed and the needed capabilities. If automatic polling is already enabled, eligible scheduled reads can use that activation; activation does not enable the polling schedule itself. Retiring the activation blocks new claims using it and leaves the polling schedule unchanged.

An explicitly selected SNMP credential must still cover the device's current site when a read starts. Restricting a district credential to another site stops those former bindings from using it. Select a credential authorized for the device's site, or correct the profile's scope, before retrying. A scope refusal does not create a device-down observation or refresh the last successful reading.

For SSH, a site credential needs an independently established target site: the read request’s site or the site recorded with the trusted host. A credential cannot establish that site merely by belonging to it. Older saved reads with neither source of site ownership must be corrected before a site credential can be used; verifying the host key alone does not establish site ownership.

1. Confirm the device's site, management address, and intended monitoring method. An address change or replacement must be reviewed against the existing identity before trusting new results.
2. In Governance › Monitoring › Configuration › Access, choose an active Device CLI credential for SSH or an SNMPv3 authPriv credential for SNMP. Check whether its scope covers the device's site. A district profile and a site profile are different choices; the presence of some saved credential does not prove this device has usable access.
3. Enter the device account and the required secret. For SNMPv3, match the username, authentication protocol, privacy protocol, and their secrets to the device configuration. For SSH, use the configured password or private key. Existing secrets are write-only in the form; an empty displayed secret is not evidence that none is stored.
4. For SSH, verify a new or changed host fingerprint through a trusted source before approving it. A changed key needs an explicit rotation decision. Do not approve an unexpected key simply to make the read succeed.
5. For governed SNMP collector reads, review device identity candidates when requested. Verifying an engine identity pins future reads to that exact identity; retirement removes that active claim. Record the reason for each identity decision.

Use the shared schedule

Applicable SSH and SNMP health, ports, neighbours, and component reads belong to the same collection cycle. There is no separate nightly port interval or priority-site cadence in this policy. A cycle is a collection window, not a promise that all devices finish simultaneously or every requested class succeeds.

Timeouts and the number of devices read at once remain under Collection limits. They constrain work within a cycle rather than create another schedule. Work that cannot finish before the cycle deadline is incomplete; the next cycle provides another opportunity. Missed intervals do not become a backlog of duplicate cycles. Changing the interval never refreshes old observation timestamps.

1. Open Governance › Monitoring › Configuration › Schedule and read the saved Automatic polling state.
2. Enable automatic polling and set Polling interval (minutes). The starting interval is five minutes; the accepted range is a whole number from 5 to 1440. An installation that previously had automatic polling off can retain that choice.
3. Select Save schedule and wait for the saved confirmation. Changing this policy requires Administrator EX with Monitoring edit access.
4. If another editor changed the policy, choose Reload schedule, review the current value, and make your change again. If the schedule cannot be read, reload it; the error does not establish whether automatic polling is enabled.

Know what each method can contribute

An SSH-bound switch can use SSH for its supported regular readings and SNMP for ports when SNMP is available. Other enrolled targets follow their available methods and bindings. Controller-owned access points can be covered by their controller instead of receiving a direct read. Do not expect both transports to contact every device.

The shared policy described here governs these SSH and SNMP device reads. It does not establish that server management, controller integrations, notifications, or every other provider uses this interval.

Scroll the table sideways to read all columns.

Understand site collector participation

A reporting collector is available to be considered; its heartbeat alone does not show that it polled a device. Check the collector activity, cycle or job outcome, and device observation. The shared scheduled path selects eligible site collectors for supported full SNMP switch reads. Scheduled SSH, manually enrolled targets, and unsupported scheduled collector bundles use the console path. Separately requested device commands and manual reads have their own collector eligibility checks.

Eligibility includes the correct site, an active and recent heartbeat, available capacity, the required capability, the current version of the credential, and matching approved collector software and read definitions. When no eligible collector is selected, the console can own the read. Once collector ownership is committed, a collector failure does not trigger a second console read for the same assignment.

Accepted collector evidence must still pass identity, time, and completion checks before it updates live device data. An expired job, stopped collector, refused clock, or missing result is a collection gap. It must not be read as a synthetic device-down observation.

When another read is already running

A scheduled read, discovery, or a manual request may already be using the same management address. Cenovel keeps that address reserved until the earlier connection has closed. A busy or stopping reader means the new request was deferred; it is not a new device failure and does not refresh the last successful reading.

Wait for the existing request to finish before retrying. A deadline or missing collector response does not prove that its device connection stopped. If the address remains busy, inspect the original job and collector instead of repeatedly submitting new requests.

When a collector eventually confirms that an expired request has closed its connection, the address can become available again. That late confirmation does not turn the expired request into a successful fresh reading. A later request must collect its own evidence.

Vendor evidence captures distinguish a device that could not be read now from a fresh answer. Earlier stored evidence remains available with its original timestamp. Check that timestamp before describing the capture as current.

Remote manual reads require approved collector software that supports permission before each connection and reliable completion reporting. Check your release notes for the collector version that supports this. Installing a version alone does not grant approval. Remote manual requests that would recursively read additional endpoint addresses are currently refused; they do not silently claim those endpoints were read.

Read freshness one class at a time

Compare the latest attempt with the last complete reading. A recent failed attempt can coexist with an older complete port table. SSH and SNMP retain their own attempt and successful-observation times; an SSH answer does not refresh an SNMP counter sample.

Complete evidence can replace the previous facts for its class. Partial, failed, truncated, or unsupported evidence cannot claim a new complete observation. Earlier useful values can remain visible with their own timestamps. A blank field therefore means unknown or unavailable unless the device positively reported an empty value.

Traffic needs comparable counter samples. The first sample establishes a baseline. A reboot, counter reset, changed interface index, collector change, or unusable interval can prevent a rate calculation. No rate is not zero traffic. Likewise, an unread power table is not proof that every supply is healthy, and a partial component inventory is not proof that an omitted part was removed.

Port summary counts describe the latest recorded attempts within the displayed period, currently the last 24 hours. They are not a guarantee that one whole cycle completed or that every enrolled device was read.

Respond to failures in order

If many devices become silent together, investigate Cenovel's reach to the management network and shared credentials before declaring many independent hardware failures. Observation conditions can hold outage handling while the monitoring system itself lacks reliable visibility.

Scroll the table sideways to read all columns.

Confirm recovery with new evidence

1. Correct the identified access, network, collector, or device issue and allow a subsequent cycle to run. Avoid repeated manual requests while earlier work is unresolved.
2. Confirm that the affected transport now has a new answer and that the specific missing class has a new complete observation time.
3. Review component and outage detail separately. A working management connection does not establish that an unread power supply recovered. A missing serial does not, by itself, establish a replacement.
4. Check the resulting device facts and incident history. Recovery should follow appropriate new evidence; acknowledgement or an interval change does not substitute for that evidence.