ERRORLOG – Parte 3: Na prática

Olá,

Esse é o último post da série ERRORLOG. Caso tenha interesse:

• Parte 1: O básico
• Parte 2: Dicas e Casos
• Parte 3: Na prática (você está aqui)

O assunto de hoje é relacionado à importância do ERRORLOG no dia a dia e a sugestão de soluções que façam proveito dele.

ERRORLOG na essência

Apesar da palavra ERROR compor o ERRORLOG, já vimos que este log do SQL Server não se limita apenas a registrar erros: registra eventos.

Dito isso, deixo aqui uma frase inteligente que catei no highscalability.com e que tem tudo a ver com o post:

• @rolandkuhn: «the event log is a database of the past, not just of the present» — @jboner at #reactconf

Em bom português: O log de eventos é um banco de dados do passado, não somente do presente. Em parábola: um log de eventos conta uma história do antes e do agora.

Alguns usam o ERRORLOG apenas para respostas pontuais (geralmente reativas), outros para verificação rotineira (pró-ativa), mas é fato de que uma hora ou outra, estes eventos se mostram de grande valor para agregar informações em nosso dia a dia, independente da abordagem que temos com estes arquivos.

Tendo dito que o ERRORLOG é um banco de dados da própria instância, concluo que:

• Se é um “banco de dados”, merece ser armazenado;
• Se é um “banco de dados”, merece ter informação extraída para agregar em análises;

Armazenamento de ERRORLOG

Acredite se quiser, mas caso você nunca tenha precisado do ERRORLOG e venha a precisar, é decepcionante digitar na unha um sp_readerrorlog e descobrir que os eventos que você queria ler já foram reciclados 🙂

Pior ainda: se numa crise brava, o ERRORLOG for sua única opção de evidência e por um motivo e outro os eventos deste se perderam…Não tem pior desculpa que: “não tem porque eu não guardei” quando alguém pergunta sobre esses eventos…

Embora o comportamento padrão do arquivo seja circular, não quer dizer que deva ficar assim. Pensar que aquelas informações podem em algum momento, trazer algum valor (ou resolver algum problema), é razão suficiente para gastar espaço em disco armazenando-os.

Faz sentido armazenar os eventos, seja realizando backup dos arquivos (via Filesystem) ou através de soluções customizadas (uma possível solução foi proposta no decorrer deste post usando T-SQL, mas podia ser via Powershell também…) de modo que se mantenha uma história do servidor e seus eventos em algum momento poderão ser úteis.

Caso não seja identificada a necessidade de armazenar essas informações, uma medida mínima para prevenir “perda de informações” (entre aspas) é de aumentar o limite de errorlogs para um número razoável, conforme citado na parte 2 da série, onde o limite máximo de arquivos (99) é uma sugestão, embora pareça exagero. A ideia aqui é perder o menor número de eventos possíveis antes que o (re)cycle leve informações embora. Como análises de eventos ocorrem em períodos próximos, pode ser que a simples solução de ter mais arquivos de log já ajude na localização de eventos mais recentes e previna alguma falta de informação caso algum evento antigo precise ser consultado.

Informação do ERRORLOG

É possível tirar alguma inteligência a partir de arquivos “brutos” de log? Tecnicamente, muitos olham o errorlog ou em casos pontuais na ocorrência de algum problema ou por possuir postura pró-ativa, mas em geral, quando se olha o errorlog, se busca uma resposta, se busca informação. Se é interessante extrair informação, principalmente de algo que vem de graça no SQL Server, dentre várias opções, não se pode ignorar os errorlogs.

Farei algumas perguntas bem despretensiosas, mas antes de ler, pense em qualquer ambiente que você tenha:

  •  Quantos KILL’s ocorrem por dia neste servidor?
  •  Quantas operações de logins com falhas, em média, ocorrem por dia? São do mesmo login?
  • Quais são os erros sérios que você descobriu quando um problema aconteceu e uma ou mais evidências estavam no ERRORLOG?

As perguntas possuem uma importância muito relativa: identificar quantidade de KILL’s em ambientes onde a prática é comum mesmo quando não deveria ser (até pelas próprias aplicações) não agrega tanto valor ter ciência desta informação, mas em uma ambiente de BI por exemplo onde o evento é mais raro, é uma informação que possui seu peso…

Quantidade de falhas de login é um número que flutua bastante, mas é interessante saber quais são os mais recorrentes e resolver na fonte o motivo do problema (Datasource com senha errada? Pela faixa de tempo é possuir concluir que seja a possível causa das requisições mal-sucedidas) até pra não sujar muito o errorlog com mensagens repetidas.

Eventos relevantes e/ou sérios: indisponibilidade, corrupções e falhas de backup, por exemplo, podem ser descobertos ou melhor investigados com o auxílio do ERRORLOG, e por isso, é interesante saber a quantidade e frequência que esses tipos de eventos (geralmente não desejados, acredito piamente, rs) acontecem, principalmente em servidores de produção.

Solução Universal para Armazenamento e Extração de Informações?

Sinceramente, não creio que exista algo assim. Cada ambiente possui uma particularidade e cada DBA também, então, pode ser que as informações do errorlog sejam lixo pra determinado ponto de vista pessoal, e luxo para outro, principalmente quando se trata de errorlogs pois não é um dos pontos de conversa mais populares e muito pouco se fala sobre (e isso foi um dos fortes motivos que me levou a escrever essa série de posts).

Mas, podemos elaborar algo que possa atender relativamente bem este propósito de  de coleta, armazenagem e extração de informação. Em determinado cenário X, identifiquei uma boa oportunidade de fazer as duas coisas ao mesmo tempo: armazenar as informações do ERRORLOG e extrair informação útil dele.

Aproveitei para formular uma solução e gostaria de apresentar aqui no blog.

Sugestão de Solução: ERRORLOG CAPTURE

Basicamente: realiza a leitura de todos os errorlog de determinada instância com o uso da xp_readerrorlog em determinado período do tempo e joga em um determinado repositório de eventos (que seria uma tabela no SQL Server, que servirá como armazenamento). A ideia aqui é coletar o que realmente for necessário e evitar informação redundante.

A segunda ideia por trás da solução é, através de uma identificação rústica de caracteres e de baixa performance (graças ao operador LIKE) e até por esse motivo trata-se de uma carga que deve ser feita em horários estratégicos, identificar padrões de mensagem e com base nesse padrão classificar determinados eventos. Ao longo do tempo, é necessário identificar eventos que não foram tratados e que não se encaixam em nenhuma categoria e organizá-los manualmente.

Um bom exemplo: Quando a mensagem de um determinado evento conter a entrada ”%LOGIN FAILED% tenho certeza de que posso enquadrar a mensagem na categoria “LOGIN”. A ideia de classificar na mão não é eficiente mas traz a liberdade de criar categorias e criterizar de acordo com a necessidade e criatividade de cada um.

A outra ideia por trás do conceito de categorizar à mão livre, é que de acordo com o ambiente, posso classificar aquela categoria como importante, pouco importante e nada importante e usar essa informação posteriormente como critério de pesquisa.

Poderia então, por exemplo:

  • Identificar a quantidade de eventos relacionados a erros graves no mês;
  • Ver quantas mudanças de estado de bases ocorreram;
  • Checar se tenho muitas entradas de logins inválidos, e através destas informações, tomar decisões de melhorias (algumas até preventivas) para o ambiente;
  • Pesquisar mensagens de uma só categoria ou pesquisar mensagens de categorias que considero críticas (erros de backup, corrupções, etc) via query;

Vantagens:

  • Conseguimos armazenar em um formato confortável (relacional, dentro do SQL Server) e que posteriormente pode ser backupeado ou expurgado conforme necessário.
  • Conseguimos retirar informações e ter mais conhecimento de nossos servidores.
  • Categorizar erros é uma ótima forma de gerenciar melhor tanta informação.

Desvantagens:

  • Depender de uma proc fechada como a xp_readerrorlog traz uma série de limitações de performances e o código possui um comportamento não-desejado SQL Server 2014 (erros são gerados pela procedure e a leitura dinâmica dos errorlogs não é realizada conforme esperado).
  • Performance não-escalável com o uso da xp_readerrorlog. Pode ser aprimorada com o uso de Powershell;

Eis o código da solução:

Você possui alguma solução em seu ambiente para armazenar e se aproveiter melhor dos errorlogs?
Críticas, sugestões? Comente 🙂

Leia também: Controlando o crescimento do ERRORLOG http://renatomsiqueira.com/controlando-o-crescimento-do-errorlog/

Leave a Comment

Your email address will not be published. Required fields are marked *