The post has been translated automatically. Original language: Russian
Personal observation, most monitoring systems start the same way.
Ping has been set up. We've checked the site. We saw a green check mark. They calmed down.
We've been working like this for many years too.
And that is why we regularly faced a situation when “monitoring showed nothing,” but the problem already existed.
The site seems to be opening. The server is responding. Ping passes.
But:
- the system starts to slow down
- customers complain about the speed
- some services are unstable
- SSL is ending soon
- the domain is about to expire
- Something breaks at night, and you only find out about it in the morning.
At some point, it became obvious that it was no longer enough for the modern infrastructure to simply check the availability of the site.
Pinguva emerged precisely from this pain.
Not like “another uptime checker". And as an attempt to create monitoring that warns about a problem before it becomes critical for business.
Why is regular ping no longer enough?
One of the main problems of the infrastructure is that most failures do not occur instantly.
Very rarely” the server just “dies" in a second.
More often than not, everything happens gradually:
- services start to run slower
- The load is increasing
- There are delays
- the infrastructure is deteriorating step by step
At the same time, the site can continue to open. And ping keeps responding.
Everything looks fine from the outside. But inside, the problem is already developing.
These are the most dangerous situations. Because businesses still don't understand what's going on, and users are already beginning to face the consequences.
We've been dealing with this all the time. Especially at night. Especially on projects with a high workload and a large number of services.
Why did we focus on simplicity?
Another thing that has always annoyed us about monitoring systems is the complicated connection.
Very often, the implementation looks like a separate infrastructure project.:
- setting up a VPN
- port forwarding
- firewall rules
- complex access schemes
- long-term agent configuration
In reality, many companies need a different approach.
To enable monitoring quickly. Without a complex network architecture. Without having to open the server to the outside.
That's why we initially followed the path of Pinguva: It is as simple as possible to connect an agent with a single command.
Without port forwarding. Without a VPN between the servers. Without complex infrastructure preparation.
Because good monitoring should save time, not create a new headache.
Why monitoring is no longer just about servers
Over time, we realized another important thing.
For a business, it doesn't matter where exactly the problem occurred.
The user doesn't think, “our SSL certificate expired” or “we have problems with DNS.”
Everything looks the same to him.: “the website is down.”
Therefore, modern monitoring should look more broadly.
Not only:
- is the server responding
- is the port open
But also:
- is SSL running out of steam
- is the domain expiring
- is HTTPS working correctly?
- are the key services available?
- are there any signs of system degradation
And preferably in advance.
What we learned during the development of Pinguva
The biggest problem of monitoring today is not the lack of data.
Conversely. There is too much data.
Charts. Metrics. Logs. Notifications. Dozens of screens.
But at a critical moment, the engineer needs an answer to only one question.: “What exactly is going wrong right now?”
Therefore, one of the main principles of Pinguva is: less noise, more clarity.
We want the system to help us see the problem before the user and understand its cause faster.
Actually, Pinguva grew out of this idea, and we hope that it will be useful.
Личное наблюдение, большинство систем мониторинга начинают одинаково.
Настроили ping. Поставили проверку сайта. Увидели зеленую галочку. Успокоились.
Мы тоже так работали много лет.
И именно поэтому регулярно сталкивались с ситуацией, когда “мониторинг ничего не показывал”, но проблема уже существовала.
Сайт вроде открывается. Сервер отвечает. Ping проходит.
Но:
- система начинает тормозить
- клиенты жалуются на скорость
- часть сервисов работает нестабильно
- SSL скоро заканчивается
- домен вот-вот истечет
- ночью что-то ломается, а узнаешь об этом только утром
В какой-то момент стало очевидно: современной инфраструктуре уже недостаточно просто проверять доступность сайта.
Pinguva появилась именно из этой боли.
Не как “еще один uptime checker”. А как попытка создать мониторинг, который предупреждает о проблеме до того, как она становится критичной для бизнеса.
Почему обычного ping уже недостаточно
Одна из главных проблем инфраструктуры в том, что большинство сбоев происходят не мгновенно.
Очень редко сервер просто “умирает” за секунду.
Чаще все происходит постепенно:
- сервисы начинают работать медленнее
- растет нагрузка
- появляются задержки
- инфраструктура деградирует шаг за шагом
При этом сайт может продолжать открываться. А ping продолжает отвечать.
Снаружи все выглядит нормально. Но внутри проблема уже развивается.
Именно такие ситуации самые опасные. Потому что бизнес еще не понимает, что происходит, а пользователи уже начинают сталкиваться с последствиями.
Мы сталкивались с этим постоянно. Особенно ночью. Особенно на проектах с высокой нагрузкой и большим количеством сервисов.
Почему мы сделали акцент на простоте
Еще одна вещь, которая нас всегда раздражала в системах мониторинга - сложное подключение.
Очень часто внедрение выглядит как отдельный инфраструктурный проект:
- настройка VPN
- проброс портов
- firewall rules
- сложные схемы доступа
- длительная настройка агентов
В реальности многим компаниям нужен другой подход.
Чтобы мониторинг можно было подключить быстро. Без сложной сетевой архитектуры. Без необходимости открывать сервер наружу.
Поэтому в Pinguva мы изначально пошли по пути: максимально простое подключение агента одной командой.
Без проброса портов. Без VPN между серверами. Без сложной подготовки инфраструктуры.
Потому что хороший мониторинг должен экономить время, а не создавать новую головную боль.
Почему мониторинг - это уже не только про серверы
Со временем мы поняли еще одну важную вещь.
Для бизнеса не имеет значения, где именно произошла проблема.
Пользователь не думает: “у нас истек SSL-сертификат” или “у нас проблемы с DNS”.
Для него все выглядит одинаково: “сайт не работает”.
Поэтому современный мониторинг должен смотреть шире.
Не только:
- отвечает ли сервер
- открыт ли порт
Но и:
- не заканчивается ли SSL
- не истекает ли домен
- корректно ли работает HTTPS
- доступны ли ключевые сервисы
- нет ли признаков деградации системы
И желательно - заранее.
Что мы поняли во время разработки Pinguva
Самая большая проблема мониторинга сегодня - не отсутствие данных.
Наоборот. Данных слишком много.
Графики. Метрики. Логи. Уведомления. Десятки экранов.
Но в критический момент инженеру нужен ответ только на один вопрос: “Что именно сейчас идет не так?”
Поэтому один из главных принципов Pinguva: меньше шума - больше ясности.
Мы хотим, чтобы система помогала увидеть проблему раньше пользователя и быстрее понять ее причину.
Собственно, из этой идеи Pinguva и выросла, надеемся что она будет полезна.
Share
