SNMP and Prometheus Monitoring in NetSmart 1.0.7: Why Use Both?

Short answer: NetSmart 1.0.7 adds two complementary monitoring interfaces. Its Prometheus-compatible /metrics endpoint exposes process and managed-service metrics for time-series collection. Its read-only SNMP v2c agent listens on UDP port 161 and exposes standard system MIB objects for traditional network management tools.

Use Prometheus when you need scrape-based metrics, dashboards, trends, and alert rules. Use SNMP when your existing network management system already polls routers, switches, servers, and appliances. Use both when infrastructure and application teams rely on different monitoring stacks and need NetSmart visible in each one.

What monitoring features are new in NetSmart 1.0.7?

• An independently controlled Prometheus-compatible /metrics endpoint
• Process metrics and managed-service metrics
• A read-only SNMP v2c agent
• Standard system MIB objects
• SNMP service on UDP port 161
• Persistent web start/stop controls
• Monitoring health status in the NetSmart interface
• Docker port and configuration support
• Deployment documentation for the monitoring services

The two interfaces are independently controlled. Administrators can enable only the monitoring path they use, reducing unnecessary listeners and simplifying firewall policy.

What is SNMP monitoring?

The Simple Network Management Protocol (SNMP) is a standard way for a management system to query information from networked devices. An SNMP agent exposes managed objects identified through a Management Information Base (MIB). A monitoring platform sends Get, GetNext, or GetBulk requests and records the returned values.

RFC 3416 defines the SNMP version 2 protocol operations, including GetRequest, GetNextRequest, GetBulkRequest, responses, and other protocol data units.

NetSmart's SNMP agent is intentionally read-only. It exposes standard system information for monitoring but does not provide a remote configuration interface through SNMP.

Why use SNMP with NetSmart?

• Existing NMS integration: add NetSmart to the same platform that monitors switches, routers, firewalls, access points, UPS devices, and servers.
• Standard discovery: use familiar system MIB objects without requiring a custom application integration.
• Inventory context: include system identity, uptime, and other standard agent data in network operations workflows.
• Simple availability polling: verify that the host and agent respond from the management network.
• Read-only operation: collect information without permitting SNMP Set operations against NetSmart.

What is a Prometheus-compatible metrics endpoint?

A Prometheus-compatible target exposes metric samples over HTTP in a defined text or OpenMetrics format. A Prometheus server or another compatible collector periodically scrapes the endpoint and stores the resulting time series.

The official Prometheus exposition documentation describes a human-readable, line-oriented format with metric names, optional labels, values, and metadata such as HELP and TYPE. NetSmart 1.0.7 exposes process and managed-service metrics through /metrics.

Why use Prometheus metrics?

• Time-series history: see whether memory, request volume, failures, or service state changed over time.
• Dashboards: visualize process and managed-service behavior in Grafana or another compatible tool.
• Alerting: define rules for unavailable services, resource pressure, repeated failures, or missing scrapes.
• Service-level detail: collect application-oriented metrics that may not map naturally to standard SNMP system objects.
• Automation: integrate health signals into incident response and capacity-planning workflows.

SNMP vs Prometheus

Question	SNMP v2c agent	Prometheus-compatible endpoint
Primary model	Management station polls MIB objects	Collector scrapes labeled metric samples
Transport	UDP port 161	HTTP endpoint
Best fit	Traditional network monitoring systems	Time-series observability, dashboards, and alerts
NetSmart scope	Read-only standard system MIB objects	Process and managed-service metrics
Configuration	Community and network access policy	Scrape target and HTTP access policy
Control in 1.0.7	Independent persistent start/stop control	Independent endpoint control

Why use both?

SNMP and Prometheus solve overlapping but different operational problems. The network team may already use an NMS built around SNMP inventory and availability polling. The platform team may use Prometheus for application metrics, trend analysis, dashboards, and alert rules. Enabling both gives each team a supported interface without forcing one tool to imitate the other.

A practical division of responsibility is:

• Use SNMP for standard system discovery and integration with the network-device view.
• Use Prometheus metrics for process behavior, managed-service state, time-series analysis, and alerting.
• Use NetSmart's own health display for administrator actions and immediate service context.

Do not create duplicate alerts without ownership. Decide which system is authoritative for each signal and document who responds.

SNMP v2c security limitations

SNMP v2c uses a community string but does not provide the authentication and encryption protections available in SNMPv3. A read-only agent prevents configuration changes through Set requests, but exposed monitoring data and the community value still require protection.

• Use a unique, non-default community value.
• Permit UDP port 161 only from approved monitoring hosts or subnets.
• Do not expose the agent to the public internet.
• Keep monitoring traffic on a trusted management network or protected tunnel.
• Rotate the community value when administrators or monitoring systems change.
• Monitor for unexpected SNMP requests and repeated authentication failures where supported.

Protecting the metrics endpoint

A metrics endpoint can reveal process behavior, service names, availability, and operational patterns. Even when it contains no credentials, it should not automatically be public.

• Allow access only from the approved scraper network.
• Use firewall rules, a private network, VPN, or authenticated reverse proxy as appropriate.
• Do not place secrets, tokens, passwords, email addresses, or unbounded user-controlled values in metric labels.
• Set a scrape interval that provides useful visibility without unnecessary load.
• Alert when the target disappears, but distinguish a deliberately disabled endpoint from a failed service.

Deployment checklist

1. Choose SNMP, Prometheus, or both based on the monitoring systems already in use.
2. Publish UDP port 161 only if the SNMP agent is required.
3. Restrict the SNMP listener to the management network and configure a unique read-only community.
4. Make the metrics endpoint reachable only by the approved scraper.
5. Add the NetSmart target to the NMS and/or Prometheus configuration.
6. Verify SNMP system objects and a successful metrics scrape.
7. Create dashboards and alerts around actionable signals, not every available value.
8. Test that monitoring detects a controlled service stop and clears after recovery.
9. Document port mappings, ownership, alert routes, and the expected disabled state.

Useful monitoring questions

• Is the NetSmart application process reachable and healthy?
• Which managed network services are running, stopped, or failing?
• Are resource trends moving toward a capacity limit?
• Did a service stop intentionally through the web control or unexpectedly?
• Has the collector stopped receiving data?
• Which team owns the response for each alert?

Frequently asked questions

Which port does NetSmart SNMP use?

The NetSmart 1.0.7 read-only SNMP v2c agent uses UDP port 161. Publish and permit that port only when an authorized monitoring system needs it.

Can SNMP change NetSmart settings?

The 1.0.7 agent is read-only. It is intended for polling standard system MIB objects, not remote configuration through SNMP Set operations.

Is the metrics endpoint enabled automatically?

NetSmart provides independent control of the Prometheus-compatible endpoint. Enable it only when a collector requires access, then protect the route with network policy.

Do I need Prometheus to read the endpoint?

No. Any collector that supports the Prometheus exposition format can scrape it, though Prometheus is the most common choice.

Should SNMP v2c be used over the internet?

No. Restrict it to a trusted management network or protected tunnel. SNMP v2c does not provide modern encrypted transport.

Does monitoring replace backups or service tests?

No. Metrics and SNMP improve visibility, but they do not replace backups, restore tests, application-level checks, logs, or incident procedures.

Visibility for both network and platform operations

NetSmart 1.0.7 makes monitoring a first-class, independently controlled capability. SNMP v2c connects NetSmart to traditional network management. The Prometheus-compatible endpoint provides richer time-series data for process and managed-service observability. Used with careful access controls and clear alert ownership, the two interfaces provide complementary views of the same self-hosted platform.

Explore NetSmart services and deployment details or review the NetSmartApp Docker Hub repository.