외부 시스템에 연결된 복잡한 애플리케이션을 유지한다고 가정 해 보겠습니다. 어느 날 특정 입력에 대해 예기치 않은 결과가 반환되기 시작하고 이유를 알아야합니다. DNS 문제, 파일 시스템 관련 문제, 외부 시스템 변경 등이있을 수 있습니다.haskell의 코드 계측
처리량이 많은 경우 문제의 가능한 위치를 식별하기 전에 원본 응용 프로그램에서 생성하지 않는 자세한 추적을 얻어야합니다.
특정 구성 요소 또는 기능에 버그가있는 비 휘발성 증명 (라이브 디버그 세션 아님)을 제공 할 수 있도록 기존 코드를 계측하려면 어떻게해야합니까?
뭔가를 오해하지 않는 한, 이것은 하스켈에 특화된 것보다 더 많은 아키텍처/모범 사례 유형의 질문처럼 들립니다.
애플리케이션에 로깅 시스템 (예 : hslogger)을 사용해야하는 것 같습니다. 일반적인 접근법은 코드의 각 구성 요소가 첨부 된 우선 순위를 가진 로깅 메시지를 생성하도록하는 것입니다. 그런 다음 응용 프로그램에 다른 우선 순위 수준을 다르게 처리하게 할 수 있습니다. 예를 들어 콘솔에 심각한 오류가 표시 될 수 있으며 디버그 및 정보 수준 오류는 로그 파일로 이동합니다.
그것은 GHC 이벤트 로그는 스레드 산란/스위칭 및 쓰레기 수거에 대한 정보를 기록 당신이, 동시성 문제를 의심하는 경우 특히 Debug.Trace.traceEvent 및 Debug.Trace.traceEventIO 대신 로깅 시스템의 사용에 때때로 유용합니다. 그러나 일반적으로 실제 로깅 프레임 워크를 대체하지는 않습니다.
또한 "불가능한"조건이 실제로 발생하지 않는지 확인하기 위해 assert을 사용하고 싶을 수 있습니다.
전적으로 당신을 따르지는 않지만, [ekg] (http://hackage.haskell.org/package/ekg)는 꽤 멋진 도구이며,'IO'에서 임의의 카운터와 값을 설정할 수있게 해줍니다. – jberryman
@jberryman 이런 소리가 좋은 대답이 될 것입니다. –