Logs, traces and monitoring
How the platform records what happened on a call or in a service, where logs and traces are collected, how operators search them, and which dashboards, alerts and health checks watch the deployment. Browse the feature map or configuration finder.
Availability: Next. Entries that depend on an optional feature, a role or a deployment choice name it in their own Availability line.
Features in this family
- Log record fields and event types
- Service log levels
- Call detail records
- Audit log of administrative actions
- Access logs (sign-in and access events)
- Audit and log retention
- Security event export to a SIEM
- Integration transaction records
- Redaction of personal data in logs
- Database projection of log records
- Role collectors and the telemetry pipeline
- Distributed tracing and call correlation
- Host and infrastructure metrics
- SigNoz observability host
- SigNoz connection for the web application
- Monitoring dashboards
- Alert rules and voice service heartbeat
- Trace debug and log search
- Conversation debug view (logs, span tree, SIP ladder)
- SIP edge log records
- SIP message capture
- Log-to-span conversion for SIP and media
- Voice service and media diagnostic logs
- Operation events
- SIP trunk probe and health records
- Service health and readiness checks
Log record fields and event types
Every service writes structured JSON records with a shared set of fields, a severity and a log type such as conversation, model usage, telephony, performance or error, so one query can follow a call across services.
For: Deployment operators, Integrators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Shared logger package used by every Node service(logType, severity, conversationId, traceId, service.name) | Common fields and representations |
Read more:
- Reference: Event families
- Reference: Common fields and representations
- Reference: Severity levels
- Troubleshoot: Service-specific investigation fields
Related features: Service log levels, Distributed tracing and call correlation, Call detail records, Database projection of log records.
Service log levels
Each service reads its own log level variable, with a shared fallback, so operators can raise detail for one component without flooding the others.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Service environment file, per-component log level variables(LOG_LEVEL, TELWEB_LOG_LEVEL, TELAPI_LOG_LEVEL, TELPHI_LOG_LEVEL, TASKER_LOG_LEVEL, TELPRO_LOG_LEVEL, TELSYS_LOG_LEVEL, AUDIOPROC_LOG_LEVEL, RTPENGINE_LOG_LEVEL, WEBRTC_LOG_LEVEL) | Set the level for each component |
Read more:
- Reference: Set the level for each component
- Reference: Variables defined on other pages
Related features: Log record fields and event types, Voice service and media diagnostic logs.
Call detail records
At the end of each call the platform writes one summary record with parties, timing, outcome and termination reason, suited for billing reconciliation and call statistics.
For: Deployment operators, Integrators, Team administrators
Read more:
- Reference: Interpret a Call Detail Record
- Reference: Read the payload
Related features: Log record fields and event types, Conversation debug view (logs, span tree, SIP ladder).
Audit log of administrative actions
Changes made through the web application and API are written as audit records with actor, action, target and source address, and administrators can read them back for their scope.
For: Team administrators, Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Web service environment, trusted reverse-proxy hops for client address(AUDIT_TRUSTED_PROXY_HOPS) | Web variables |
Read more:
- Reference: Audit action catalogue
- Reference: Audit transport markers
- How it works: Audit records in SigNoz
Related features: Access logs (sign-in and access events), Audit and log retention, Security event export to a SIEM.
Access logs (sign-in and access events)
Platform administrators see sign-ins, failed attempts, lockouts and session events on one admin page and can filter them by user, time and outcome.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Platform settings | Admin Settings › Access Logs(/admin-settings/access-logs) | Investigate an access event |
Read more:
- Set it up: Investigate an access event
- Set it up: 1. Find a known event and record
Related features: Audit log of administrative actions, Security event export to a SIEM.
Audit and log retention
Audit rows in the database are pruned by a daily job, while copies in SigNoz and in an external SIEM follow their own retention, so each copy needs its own retention decision.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Tasker cron schedule and retention variables(audit-log-cleanup, AUDIT_LOG_RETENTION_DAYS, SIGNOZ_RETENTION_DAYS) | 4. Establish retention for each copy |
Read more:
- Set it up: 4. Establish retention for each copy
Related features: Audit log of administrative actions, Security event export to a SIEM, Background jobs and schedules.
Security event export to a SIEM
An optional export collector forwards records flagged as security events to Splunk HEC or Dynatrace, separately from the main SigNoz pipeline, with its own health endpoint and delivery limits.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Observability host environment, export collector variables(SIEM_HEC_ENDPOINT, SIEM_HEC_TOKEN, SIEM_HEC_INDEX, SIEM_HEC_CHANNEL, DYNATRACE_OTLP_ENDPOINT, DYNATRACE_API_TOKEN, OTEL_EXPORT_BACKEND_HOST, security_event) | 2. Check the external feed separately |
Read more:
- Set it up: 2. Check the external feed separately
- Reference: 3. Verify selection, protection and delivery limits
- Reference: Rejected calls and security tagging
Related features: Audit log of administrative actions, Access logs (sign-in and access events), Audit and log retention, Role collectors and the telemetry pipeline.
Integration transaction records
Calls from flows to external HTTP integrations are logged as request and response transactions with timing and status, and payload bodies are recorded only when payload logging is switched on.
For: Deployment operators, Integrators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Service environment, integration payload logging switch(LOG_INTEGRATION_PAYLOADS) | Control payload logging |
Read more:
- Reference: Transaction records
- Set it up: Control payload logging
- Reference: Security tags on transaction records
Related features: Redaction of personal data in logs, Distributed tracing and call correlation.
Redaction of personal data in logs
Phone numbers are masked to their last digits and known secret fields are redacted before records leave a service, with a collector-side masking stage as a second layer and a switch for unmasked diagnostics.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Service environment, masking variables(MSISDN_UNMASKED_DIGITS, ENABLE_PII_LOGGING) | Protect diagnostic logs before sharing |
Read more:
- How it works: Protect diagnostic logs before sharing
- Set it up: Add installation-specific redaction rules
- Reference: Adjust a masking rule
- How it works: Personal data in telemetry
Related features: Log record fields and event types, Integration transaction records.
Database projection of log records
With database logging on, audit entries land in the audit table and other domain entries in an application log table with a few searchable columns, so some history stays readable without SigNoz.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Service environment, database logging switch(ENABLE_DB_LOGGING) | Database projection |
Read more:
- Reference: Database projection
Related features: Log record fields and event types, Conversation debug view (logs, span tree, SIP ladder).
Role collectors and the telemetry pipeline
Each host role runs an OpenTelemetry collector that gathers container logs, traces and host metrics, enriches them with role and environment and forwards them to the observability host.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Host environment, collector and backend variables(OTEL_ENABLED, OTEL_BACKEND_HOST, OTEL_BACKEND_ENDPOINT, SIGNOZ_OTLP_GRPC_ENDPOINT, SIGNOZ_OTLP_HTTP_ENDPOINT) | Collectors on each role |
Read more:
- How it works: How telemetry reaches SigNoz
- Reference: Collectors on each role
- Set it up: Change a collector configuration
- Troubleshoot: Check the delivery path
Related features: Distributed tracing and call correlation, Host and infrastructure metrics, SigNoz observability host, Security event export to a SIEM.
Distributed tracing and call correlation
Services export OpenTelemetry spans, and a trace identifier carried in SIP and HTTP requests ties the edge, the voice service and the conversation runtime into one trace per call.
For: Deployment operators, Integrators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Service environment, OpenTelemetry exporter variables(OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_SERVICE_NAME, OTEL_SERVICE_NAMESPACE, OTEL_DEPLOYMENT_ENVIRONMENT) | Correlation |
Read more:
- How it works: Correlation
- Set it up: Call and transaction correlation
Related features: Role collectors and the telemetry pipeline, Log-to-span conversion for SIP and media, Trace debug and log search.
Host and infrastructure metrics
Collectors scrape CPU, memory, disk and network figures from each host plus PostgreSQL and Redis statistics, and these feed the infrastructure dashboards.
For: Deployment operators
Read more:
- Reference: Collectors on each role
- Reference: Dashboards
Related features: Role collectors and the telemetry pipeline, Monitoring dashboards.
SigNoz observability host
The observability host runs SigNoz with its ingester, ClickHouse storage and web interface; operators open it to query logs and traces and upgrade it as a unit.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Observability host environment(SIGNOZ_VERSION, SIGNOZ_DATA_DIR, CLICKHOUSE_IMAGE, DOMAIN_SIGNOZ) | SigNoz app, ingester and ClickHouse |
Read more:
- How it works: SigNoz app, ingester and ClickHouse
- Set it up: Open SigNoz and its views
- Set it up: Upgrade or migrate the SigNoz host
- Reference: SigNoz variables
Related features: SigNoz connection for the web application, Monitoring dashboards, Alert rules and voice service heartbeat.
SigNoz connection for the web application
The web application reads logs and spans from SigNoz with an API key stored in platform settings, and waits a configurable delay before saving span trees and SIP ladders with a conversation.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Platform settings | Admin Settings › Platform Settings › SigNoz Observability(signoz, SIGNOZ_URL, SIGNOZ_API_KEY, SIGNOZ_SPAN_PERSIST_DELAY_SECONDS, SIGNOZ_SIP_LADDER_PERSIST_DELAY_SECONDS) | Other Platform Settings controls |
Read more:
- Reference: Other Platform Settings controls
- Reference: SigNoz variables
- Reference: Verify SIP ladder and span tree persistence
Related features: SigNoz observability host, Conversation debug view (logs, span tree, SIP ladder), Trace debug and log search, Platform settings.
Monitoring dashboards
A set of prepared SigNoz dashboards covers call volume and errors, SIP trunks, AI provider latency, voice service health and host resources.
For: Deployment operators
Read more:
- Reference: Dashboards
Related features: Alert rules and voice service heartbeat, Host and infrastructure metrics, SigNoz observability host.
Alert rules and voice service heartbeat
Prepared alert rules fire on call error spikes, an unreachable SIP trunk, missing voice service traces, speech provider failures and conversation runtime crashes; the voice service heartbeat span drives the no-traces rule.
For: Deployment operators
Read more:
- Reference: Alert rules
- Set it up: Apply or update the alert rules
- Reference: TelPhi heartbeat and the no-traces alert
- Troubleshoot: No-traces alert
Related features: Monitoring dashboards, Voice service operation, SIP trunk probe and health records.
Trace debug and log search
Platform administrators search logs and traces by call identifier, phone number or trace ID from an admin page and open the span tree, log list and SIP ladder of a match.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Platform settings | Admin Settings › Trace Debug(/admin-settings/trace-debug) | Find a trace without an open conversation |
Read more:
- Set it up: Find a trace without an open conversation
- Reference: Choose a query mode
Related features: Distributed tracing and call correlation, Conversation debug view (logs, span tree, SIP ladder), SigNoz connection for the web application.
Conversation debug view (logs, span tree, SIP ladder)
The debug area of a conversation shows the logs, span tree and SIP message ladder for that call, read live from SigNoz and kept with the conversation after a short delay.
For: Team administrators, Application builders, Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Team settings | Conversations › conversation › Debug(/conversations/[id]) | Search the logs of a call |
Read more:
- Set it up: Search the logs of a call
- How it works: Search the logs of one conversation
- Reference: Verify SIP ladder and span tree persistence
Related features: Trace debug and log search, SigNoz connection for the web application, Call detail records, Database projection of log records.
SIP edge log records
The SIP edge writes one structured record per request and reply with method, response code, call identifier and source address, tagged for security events where a request is refused.
For: Deployment operators, Integrators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | TelPro environment, structured logging switch(STRUCTURED_LOGGING_ENABLED) | Structured SIP proxy records |
Read more:
- Reference: Structured SIP proxy records
- Reference: Where SIP records land
- Reference: Native proxy lines
- Reference: Rejected calls and security tagging
- Set it up: Find SIP records
Related features: SIP message capture, Edge source verification and call token checks, Security event export to a SIEM.
SIP message capture
An optional capture writes complete SIP messages as log records so operators can rebuild the ladder of a call, with headers that carry personal data masked.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | TelPro environment, SIP capture variables(SIP_CAPTURE_ENABLED) | SIP message captures |
Read more:
- Set it up: Search the logs of a call
- Reference: SIP message captures
Related features: SIP edge log records, Conversation debug view (logs, span tree, SIP ladder).
Log-to-span conversion for SIP and media
A small converter on the edge and voice hosts turns SIP and media log lines into trace spans keyed by call, so signaling and RTP appear in the same trace as the application work.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Edge and voice host environment, converter variables(LOG_TO_SPAN_OTLP_ENDPOINT, LOG_TO_SPAN_EXPORT_LOGS) | Collectors on each role |
Read more:
- Reference: Collectors on each role
- Reference: TelPro variables
Related features: Distributed tracing and call correlation, SIP message capture, Role collectors and the telemetry pipeline.
Voice service and media diagnostic logs
The voice services write Asterisk console logs and optional per-packet media logs for deep call diagnosis; media logging is off by default because of its volume.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Voice host environment, media and console logging variables(TELPHI_ENABLE_MEDIA_LOGGING, ENABLE_MEDIA_LOGGING, ENABLE_PACKET_LOGGING, LOG_MEDIA_EVERY_N_PACKETS) | Read Voice logs |
Read more:
- Troubleshoot: Read Voice logs
- Reference: Voice variables
Related features: Service log levels, Voice service operation.
Operation events
Trunk and edge maintenance, configuration refresh, certificate updates and autoscaling emit versioned operation records with a kind and outcome, which operators can filter and alert on in SigNoz.
Availability: Available from 0.9.19.
For: Deployment operators
Read more:
- Reference: Monitor maintenance and scaling operations
Related features: Background jobs and schedules, Role collectors and the telemetry pipeline.
SIP trunk probe and health records
Periodic OPTIONS probes toward each trunk produce health records and a trunk status that the API exposes and the trunk-down alert watches.
For: Deployment operators
Read more:
- Reference: Trunk probe records
- Reference: Trunk health monitor records
- Reference: TelAPI trunk health messages
Related features: Alert rules and voice service heartbeat, Service health and readiness checks.
Service health and readiness checks
Services answer health, liveness and readiness requests and the API also publishes Prometheus-style metrics, so operators and orchestration can tell a running process from one that is ready for calls.
For: Deployment operators
Read more:
- Set it up: 2. Understand the probe before trusting it
- Set it up: 1. Inspect state without replacing it
- Reference: Heartbeat and call admission
Related features: SIP trunk probe and health records, Alert rules and voice service heartbeat, Voice service operation.