Tentativa de Shutdown #fail

rena

Olá,

Hoje aconteceu uma situação engraçada. Um integrante da equipe (codinome Juliana meu óculos) na qual faço parte estava verificando logs de servidores (produção) e encontrou uma mensagem que a princípio é preocupante:

psd1

Mensagem:

The attempt by user %2 to restart/shutdown computer %1 failed

Porque é preocupante?

  • Trata-se de uma máquina em ambiente de produção onde roda uma instância SQL Server (em cluster, então menos mal);
  • A tentativa foi feita no meio da tarde onde a indisponibilidade do serviço, se viesse a ocorrer o move, é ainda mais percebida;
  • O usuário é um DBA da equipe;
  • Ficamos preocupados com  o DBA (codinome Bozo)  porque não conseguir fazer um shutdown é fim de carreira, kkkkkkk
  • Questionamos  o DBA e ele afirmou que não tentou desligar máquina nenhuma.

Ele relatou que neste mesmo horário logou, fez atividade X no servidor e fez logoff.  Após a conversa, chegamos a conclusão do que de fato a mensagem estava representando, já que o servidor não foi reiniciado e de fato não houve nenhuma tentativa de shutdown.

Porque isso ocorre?

Quando um logoff é realizado e existem aplicações abertas, é possível que o Windows apresente a tela de Force (Logoff), informando que antes de realizar logoff/shutdown/restart, um ou mais programas precisam ser finalizados. O usuário pode escolher por forçar o desligamento OU cancelá-lo, e a segunda opção faz com que o Windows registre isso como uma “tentativa” de shutdown.

psd2

Foi exatamente isso o que aconteceu com nosso colega.
Depois que comprovamos o fato, zuamos ele e seu apelido hoje é Quase Shutdown.
Já sabe: se você ver um cenário parecido, lembre desse post 🙂

[]’s

Complementos

Mensagem de log https://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Windows+Operating+System&ProdVer=5.2&EvtID=1073&EvtSrc=User32&LCID=1033

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/

Controlando o crescimento do ERRORLOG

Finge que é o errorlog =p

Olá,

Recentemente comecei uma pequena série sobre ERRORLOG composta de três partes. Antes de prosseguir com o post de hoje que é um extra ao assunto, apresento os posts da série caso tenha interesse:

Sendo direto ao ponto: Ter um ERRORLOG grande não é algo comumente desejado, por vários motivos:

  • Demora ao abrir o arquivo: É frustante abrir arquivos grandes principalmente quando queremos uma resposta rápida e experimentamos lentidão.
  • Dificulta manipulação do arquivo: Para esta finalidade, queremos arquivos de fácil manipulação e o tamanho é um dos fatores cruciais pra essa condição.
  • Evita estouro em disco: Em geral não é algo a se preocupar, pois depende do ambiente. Mas imagine que você não precise manter o errorlog no C:  com pouco espaço e as bases de sistema também estão neste disco. Caso mudar o local não seja possível  (cenários e cenários…) você precisa se certificar que um arquivo de errorlog não seja o responsável pela parada de uma instância inteira comprometendo o disco e prejudicando por exemplo, o tempdb.

Dito isso, tenho a opinião de que é interessante controlar o crescimento dos logs aqui citados. Existe uma solução pouco conhecida (e citada aqui pelo Paul Randal) que automaticamente dispara um recycle quando determinado threshold é alcançado mas funciona apenas no SQL Server 2012 ou superior (build à consultar…)  realizando algumas alterações no registro.

É possível confeccionar uma solução destas no SQL Serer 2008 R2? Sim, e vai de cada cenário e necessidade… Sugiro aqui uma solução não-reativa: um script que pode (idealmente) ser agendado via SQL Server Agent e rodado diariamente, podendo fazer o recycle ou não sob determinadas condições. Destaco que a solução abaixo atende bem um cenário X mas não necessariamente Z ou Y, já que existem N formas de endereçar uma solução para o assunto.

Você implementa(ou) alguma solução parecida no seu ambiente ou outra bem diferente? Alguma opinião sobre o assunto? Sinta-se à vontade para postar.


Semana que vem fecho a série de ERRORLOG e prometo mais posts voltados para infra, mas de uma forma um pouco diferente, fugindo do convencional.

[]’s

ERRORLOG – Dicas e casos (parte 2 de 3)

bart2

Olá,

Continuando a série de posts sobre errorlog (você pode ler a parte 1 clicando aqui), vamos revisitar conceitos mais importantes explicados no post anterior e comentar sobre dicas/boas práticas. Caso hajam testes, indico que devem ser feitos em ambiente de teste (pelo amor de tudo o que você mais ama, rs).
Os tópicos são:

1) Conceito de (Re)Cycle;
2) Aumentar quantidade de ERRORLOGS;
3) Necessidade do ERRORLOG
4) ERRORLOG + DBCC’s

ERRORLOG – O básico (Parte 1 de 3)

Errorlog01

Olá,

Estava planejando tem um tempão falar  sobre os recursos que o SQL Server oferece de graça para os usuários do produto (supondo que estejam utilizando a versão Enterprise e/ou que tenham permissão suficiente, é claro) e inevitavelmente me veio a forma mais básica de logging do SQL Server: ERRORLOG. Esse post é o primeiro de uma trilogia, onde vamos comentar o básico e o que realmente precisa ser entendido sobre o funcionamento do mesmo.