Temos que ter en conta o tempo que os aspectos como a seguridade e as probas deben terse en conta durante o conxunto Ciclo de vida do proxecto, desde as súas orixes ata a súa conclusión. Que non son requisitos non funcionales non funcionales ou secundarios, se non son prioritarios como parte da estrutura fundamental do aplicador (non son tan funcionalidades ou mecanismos que foron deseñados e implementados a conclusión do proxecto como adición , se se fixeron). Non obstante, o rastro de aplicación, aínda que fixo mérito, non recibiu en moitos casos a mesma consideración; – p.
Neste post non creo que descubra nada novo para aqueles que teñen experiencia no desenvolvemento .. A idea é exercer a síntese e a revisión para resumir o que, ao meu xuízo, son as mellores ou boas prácticas do rexistro de aplicacións. Por suposto, as contribucións, as observacións, os matices e as críticas son benvidas; Invítovos a unirse a este exercicio.
O rexistro ou rastro de aplicación é o procesamento e almacenamento de información sobre a execución dunha aplicación. Contén datos de entidades, cambios de estado e compoñentes de software implicados nesa execución. A súa principal funcionalidade é facilitar a monitorización ou análise da execución da aplicación:
- Analizar o comportamento da aplicación durante a fase de desenvolvemento e depuración (probas de caixa branca)
- Analizar os erros ou erros de execución detectados, as súas causas e consecuencias
- serven como rexistro de auditoría cando a información contida e o modo en que se procesou cumpre os criterios necesarios
- mide o rendemento ou a carga de sistemas ou aplicacións
- reverter o estado da aplicación seguinte ao pedido inverso o rexistro
depende das circunstancias nas que nos atopemos, o O segundo dos usos adoita ser o máis relevante. Un bo rexistro desenvolvido correctamente no código e mantido ou configurado en funcionamento é unha garantía de resposta rápida para a análise de erros; Isto podería ata ser feito sen necesidade de deter a aplicación, reconfiguralo ou aplicar calquera cambio.
O rastro de aplicación normalmente está formado por un conxunto de eventos que se almacenan secuencialmente, normalmente na orde en que eles ocorrer, persistente ou recuperable. Poden ser almacenados en arquivos, en BBDD, en compoñentes distribuídos para iso … mecanismos de rotación ou historification pode ser activado, poden ser empregados por monitores para lanzar alertas, poden ser integrados e fundidos para facer análises máis exhaustivas .. . A correspondente é que a información rexistrada e como se pode ser útil.
Hai numerosas solucións e propostas de software, tanto gratuítas como máis completas, máis ou menos estandarizadas, máis sinxelas ou máis completas, de mil Tipos e formularios. O importante é buscar que se adapte ás nosas necesidades e ambientes, para esquecer a implementación do mecanismo por completo; e manter os dous aspectos máis importantes:
- O contido de cada rexistro ou evento, a principal preocupación do desarrollador
- a forma en que se procesa, persiste e Xestiona, a principal preocupación do funcionamento do sistema ou aplicador
O custo de implementación do rexistro está no IR, mentres se desenvolve, deixando rastrexar en diferentes puntos do código. Esta actividade debe realizarse durante o desenvolvemento, os seguintes patróns, criterios e procedementos preestablecidos. Deste xeito, os desenvolvedores terán criterios comúns e o rastro será consistente entre as distintas partes do código.
O rastro e documentación do código pode ter puntos en común en canto á súa filosofía, obxectivos e Modo de aplicación, pero hai unha diferenza importante entre os dous: mentres que a documentación do código entra no por que algo se fai así, o rastro debe cubrir o que está feito. Ao configurar un exemplo, nun ciclo a documentación do código debe indicar por que os límites ou as condicións de saída son tales e o rexistro de rastro durante a execución en que punto dixo que a condición de saída foi cumprida.
Información rexistrada no O rastro debe ser relevante e completo. Podes considerar os seguintes aspectos ao decidir que información inclúen:
- Que:
- Que evento ou acción aconteceu.
- Que entidades teñen estado implicado.
- Se hai un cambio de estado, cal foi a anterior? Cal é o novo estado?
- onde:
- A que punto do código ocorreu: compoñente, clase, ficheiro de código, método ou bloque de execución, liña de código … como Moito máis detallado é mellor esta información para localizar o lugar de posible erro ou onde pasou a execución, por unha banda; Pero máis pode afectar o rexistro de rendemento (a información de depuración pode ser necesaria) e a conclusión da información de rastrexo, por outra.
- cando:
- Rexistrarse temporal momento, absolutamente ou relacionado co inicio da execución ou calquera outro evento.
- Xerando un seguimento secuencial ou causal, no que os acontecementos que ocorren no tempo ou causan outros, aparecen antes.
- En que contexto:
- Rexistro de estados ou variables: executándose (parámetros), personalización ou específico do usuario, referente á sesión ou transacción que executa …
- que indique fíos, transaccións ou solicitudes relacionadas cando estamos en ambientes concorrentes.
Para a información de seguimento é máis detallada no momento da análise e Máis manexable durante a explotación diso, establécense niveis de filtrado. De tal xeito que só estes eventos móstranse ou se almacenan cun nivel maior ou igual ao nivel de seguimento establecido. As bibliotecas de rexistro permiten que os eventos filtren eventos por outros criterios como a clase ou o contexto do evento.
Os niveis máis comúns son depuradores, información, aviso e erro. A clasificación de diferentes eventos en cada nivel forma parte do exercicio de análise e debe estar dirixido ao feito de que o rastro é lexible e útil nos diferentes contextos da aplicación, desde o desenvolvemento ata a explotación.
Isto pode ser un exemplo de semántica dos niveis de rexistro:
- depuración, por información de nivel moi baixa útil para a depuración da aplicación, tanto no desenvolvemento como na análise de incidentes
- Chamadas a funcións e procedementos e outros compoñentes, con parámetros e respostas
- Desenvolvemento de algoritmos e procedementos que permiten identificar e seguir a súa execución de desenvolvemento
- Información de nivel superior que permite monitorizar a execución normal
- paradas e paradas de servizos e sistemas
- parámetros críticos ou configuración relevante
- Inicio e fin de transaccións e operacións completas
- cambios de Estado de operacións
- Aviso, información de situacións, que aínda sen ser erro, se anormal ou non prevista, aínda que a aplicación ten alternativas para resolvelas
- non parámetros definidos, e cuxo valor é tomado por defecto
- situacións anómalas, pero que están resoltas pola aplicación, deixando a operación nun estado correcto
- funcionalidades non primordiais ou esenciais, iso Non poden ser resoltos, pero deixan a operación nun estado correcto
- Erro, información de situacións que son Erro e que impiden a correcta execución dunha operación ou transacción, Pero sen afectar a outras operacións ou transaccións (erro ou contido illado)
- Non se puido realizar ningunha operación ou transacción, pero non afecta a outras solicitudes
- ou consultas erróneas (almacenando os parámetros de Entrada)
- funcionalidades xerais da aplicación, que aínda afectan o funcionamento xeral da solicitude IVO, non se consideran primordiais ou esenciais
- FATAL, información de erro de erro que afectan o funcionamento xeral da solicitude (erros ou contidos sen insular)
- Parámetros non definidos ou configuración errónea
- Falta de conexión ou comunicación con outros compoñentes
- erros de execución que poden afectar as operacións ou as transaccións independentes ou que afecten o funcionamento xeral da aplicación
tanto o contido como a forma de cada evento de rexistro, como a semántica dos niveis forman parte do deseño da aplicación. Estes criterios deben ser definidos e comunicados ao equipo de desenvolvemento para aplicar de forma homoxénea e coherente ao longo do desenvolvemento. Se estes criterios están de acordo co equipo pode obter moita vantaxe da experiencia do desarrollador.
Outras recomendacións a ter en conta son:
- Rexistrar eventos dun xeito Atómica, que toda a información sobre un evento está almacenada nun rexistro ou liña.
- Guía o formato da información que se mostra a ser usado de forma informatizada ou automática con ferramentas específicas.
- En canto ás excepcións:
- Amosar sempre o rastro completo da excepción coa súa mensaxe e todo o stacktrace.
- Se a excepción é capturada, tratada e logo lanzada de novo (ben o mesmo ou outro) non deixa rastros da excepción ata que sexa capturado e, en definitiva. Deste xeito, cada excepción só se mostrará unha vez. Se non o facemos así e rexistrar cada captura e relanzamento aparecerá no rastro varias veces e non saberemos se é o mesmo ou é varios. (Antipatron Catch-log-throw).
- facer uso da proba de excepción causada ou interna cando capturamos e recibimos a excepción. En Java é o método GetCouse (), en .NET a InnerException propiedade.
- facer uso de mecanismos MDC / NDC (información de contexto) Para ambientes de múltiples fíos ou áreas de transacción. Esta información pode permitirnos filtrar ou especificar a información de rexistro nun contexto comercial específico, como clientes, usuarios, produtos …
- implementar o método Tostring () de todas as clases de empresas ou picos para facilitar o seu tracaado.
- Ten que tomar as diferenzas e as zonas horarias en conta cando se traballa con rexistros de varias máquinas ou compoñentes.
- O rexistro non pode ter efectos secundarios, non pode modificar o estado de calquera parámetro, variable ou procedemento. Mostra só información. Debe ser lixeiro, o rexistro en si pode non requirir procesamento longo ou caro.
- chamadas a métodos, compoñentes e compoñentes distribuídos externos, incluídos os parámetros de entrada e resposta, así como a clase / Componente e método, a nivel de depuración. E ao erro e ao nivel fatal cando se produce un erro na chamada (se unha excepción debe ter parámetros de rastreamento, entrada e excepción)
un saúdo,
Juan Francisco Adame Lorite
