![](http://webcf.waybackmachine.org/web/20201117230056im_/https://habrastorage.org/getpro/habr/avatars/b09/2c9/17e/b092c917e7f287b93481ae40ee4a2d43.png)
Классифицируем ошибки из PostgreSQL-логов
В логах работающих систем рано или поздно появляются тексты каких-то ошибок. Чем таких систем больше в обозримом пространстве, тем больше вероятность ошибку увидеть. Серверы PostgreSQL, которые находятся под нашим мониторингом ежедневно генерируют от 300K до, в неудачный день, 12M записей об ошибках.
И такие ошибки — это не какой-то там «о, ужас!», а вполне нормальное поведение сложных алгоритмов с высокой степенью конкурентности вроде тех, о которых я рассказывал в статье про расчет себестоимости в СБИС — все эти deadlock,
could not obtain lock on row in relation …
, canceling statement due to lock timeout
как следствие выставленных разработчиком statement/lock timeout.Но есть ведь и другие виды ошибок — например,
you don't own a lock of type ...
, которая возникает при неправильном использовании рекомендательных блокировок и может очень быстро «закопать» ваш сервер, или, мало ли, кто-то периодически пытается «подобрать ключик» к нему, вызывая возникновение password authentication failed for user …
![](https://webcf.waybackmachine.org/web/20201117230056im_/https://habrastorage.org/webt/qk/yr/78/qkyr781jndcrofru0piaemvxaqy.png)
Собственно, это все нас подводит к мысли, что если мы не хотим потом хвататься за голову, то возникающие в логах PostgreSQL ошибки недостаточно просто «считать поштучно» — их надо аккуратно классифицировать. Но для этого нам придется решить нетривиальную задачу индексированного поиска регулярного выражения, наиболее подходящего для строки.