Know about a failure before users do, and know why it happened
I centralise metrics and logs from your ERP, integrations and infrastructure, with alerts to the owner by chat and technical dashboards.
36questions on alerts, incidents and backups, in 8 minutes
Metrics, logs and alerts in one place
Observability collects metrics, logs and traces from applications and infrastructure to know whether they work, spot anomalies and investigate the cause of a failure.
Monitoring tells you something went down; observability helps you understand why. Both are useful only if each alert reaches someone who can act.
Signs your company needs one
- Users report the outages
- Application logs are lost after a few days
- Nobody knows which process is eating memory or disk
- An update fails and there is no way to see what happened
- There are no email or chat alerts on errors
- Backups are not checked
Observability: who it is for and when it does not fit
A good fit for
- Companies whose ERP, store or integrations fail and find out from a user complaint
- Small IT teams looking after their own servers and cloud services
- Managers who need to know whether backups can be restored
Not a fit when
- Everything runs on managed services with vendor monitoring and nobody will answer in-house alerts
- There is no on-call person or agreement on who responds out of hours
- A showy dashboard is wanted without deciding which failure matters to detect
The cost of staying as you are
Longer outages
Every minute between the failure and the user’s complaint is downtime nobody was handling.
Recurring causes
Without logs or analysis, the same problem comes back and is fixed again by restarting.
Failing backups
A backup that failed silently is discovered on the day a restore is needed.
How I assess observability in four steps
I start from outages that already happened. Each alert has an owner and a procedure; one nobody answers is removed.
I identify what is critical
Services, integrations, scheduled jobs, hours and owner of each.
I collect signals
Server and application metrics, centralised logs and backup checks.
I define useful alerts
Each alert with a threshold, on-call owner, channel and instructions.
I measure and tune
Availability, time to detect and recover, and removal of alerts that need no action.
What your company provides for the observability and monitoring project
Service inventory
Servers, databases, integrations and cloud services, each with its owner.
Technical access
Users to install agents or read metrics and logs on each machine.
Who gets each alert
The owner per service and the channel: team chat, email or phone.
Incident history
Last year’s outages and how they were detected, to decide what to watch first.
From assessment to implementation
Monitoring platform
Grafana, Loki and Prometheus or another platform, with centralised metrics and logs.
Alerts and dashboards
Alerts to the owner by chat, technical dashboards and runbooks.
Backups and continuity
Daily backup checks and scheduled restore tests.
Diego Muñoz
I implement observability with open-source tools (Grafana, Loki and Prometheus) or the platform you already have: centralised metrics and logs, alerts to the owner by chat, technical dashboards and backup checks, for the ERP, integrations and infrastructure.
I implement this type of system
Take the assessmentMarket options
Between open source and commercial platforms, cost per log volume, who maintains the platform and the depth of application tracing all change.
Other platforms I assess
- Grafana + Loki + Prometheus (código abierto)
- Datadog
- New Relic
- Elastic Observability
- Dynatrace
Selection criteria
- How many servers and services to watch
- Log volume and retention period
- Alert channels your team already uses
- Open source on your own server or a cloud service
- Who runs the platform day to day
Observability: limits and alternatives
ERP on the vendor’s cloud
On Odoo.sh or other SaaS, no agents go on their servers. Monitoring is external: uptime, response times, queues and integrations.
Round-the-clock on-call
I configure alerts and procedures; out-of-hours response is covered by your team or a contracted service.
Log retention
Keeping more months of logs costs storage. The period is set by what audit requires and what is actually consulted.
Which other systems it connects to
IT service management
Alerts open incidents with an owner and deadline.
See the systemHelp desk and customer support
Support is notified when a failure affects customers.
See the systemIntegration platforms (iPaaS/ESB) and APIs
Each integration with its alert and metric.
See the systemIdentity and access management (SSO)
Access logs and alerts on unusual logins.
See the systemBusiness intelligence and data warehouse
Availability and timings in IT management dashboards.
See the system36 questions and 8 minutes to see where to start
This assessment measures how you detect, investigate and fix failures in your applications, integrations and infrastructure. The questions describe observable facts, such as where logs end up or who receives an alert on a Sunday.
Scored dimensions
- Outage response and root cause. It looks at whether an outage has a response procedure, owners and user notice, and whether its cause and the preventive action are recorded afterwards.
- Logs, metrics and traces. It looks at whether application and infrastructure logs, metrics and traces are kept in a common place, with history, search and dashboards.
- Alerts and coverage. It looks at which services, integrations and scheduled jobs are monitored, and whether alerts reach an owner with a defined action.
- Detection and availability. It looks at how long it takes to learn about a failure and to recover, and whether each service's availability is measured against a target.
- On-call and runbooks. It looks at who responds outside office hours, how fast, and whether there are written runbooks a second person can follow.
- Backups and data in logs. It looks at whether backup completion is monitored and whether technical logs exclude secrets and sensitive data, with role-based access and defined retention.
What you receive
When you finish, you receive your level in six observability dimensions and the gaps ranked by priority, each with its first verifiable action.
18 scored questions and 13 context questions (type of operation, size, current system). Context questions are not scored: they let us read the result against similar operations.
Free of charge. Only Diego Muñoz sees your answers.
Before you start
Not necessarily. Open-source tools cover metrics, logs and alerts, and they are what I use on my own infrastructure. A commercial service makes sense when you do not want to run the platform.
Availability from the outside, integrations, scheduled jobs and readable errors. The vendor watches the infrastructure.
Review each alert: if it calls for no action, tune the threshold or remove it. The goal is that every alert that arrives deserves attention.
The online assessment and the 30-minute review with Diego are free and carry no commitment.
Only Diego Muñoz sees them, to prepare the review. They are not shared with third parties or used for bulk mailings.
Review your observability case with Diego in 30 minutes
Diego Muñoz replies in person, on Lima time. If you have taken the assessment, he comes with your answers already read.
WhatsApp +51 919 488 260 · damunoz@dmunozgroup.com