web-dev-qa-db-ja.com

プログラムを運用するのに最適なHaskellライブラリは何ですか?

プログラムを運用環境に導入する場合、そのプログラムが "運用可能"であると見なすには、そのプログラムを実行する必要があります。つまり、エンジニアと運用スタッフの両方が測定可能かつ検証可能な方法で実行および保守できます。私の目的では、運用可能なプログラムは次の要件を満たしている必要があります。

  • 複数のレベルでログを記録できる(例:デバッグ、警告など)。
  • プログラムが実行している作業の種類とその作業にかかる時間に関するメトリック/統計を収集して共有できるようにします。理想的には、収集されたメトリックスは Ganglia のような一般的に使用されている監視ツールと互換性のある形式で利用できるか、またはそのように変更できます。
  • プログラムを再起動せずに、実行中のプログラムで構成されたプロパティを更新できるシステムを介して、理想的には構成可能にする。
  • 繰り返し可能な方法でリモートサーバーに展開できる。

Scalaの世界には、少なくとも最初の3つの要件に対処するための優れたライブラリがあります。例:

Scalaの世界で採用されているアプローチの1つは、プログラムを構成するバイトコードとライブラリを Assembly-sbt のようなものでバンドルし、その結果をプッシュすることです。 SSH経由でコマンドを並列実行する Capistrano のようなツールを使用してリモートサーバーにバンドル(「ファットJAR」)します。これは言語固有のツールを必要とする問題ではありませんが、そのようなツールはHaskellコミュニティに存在します。

おそらく、私が上記で説明した特性を提供するHaskellライブラリがあるでしょう。利用可能なライブラリのうち、「最良」と見なされているものを教えてください。つまり、Haskellコミュニティで一般的に使用されている、最も成熟し、よく管理されている、Haskellのベストプラクティスの例です。

Haskellのコードを「本番対応」にするためのライブラリ、ツール、または実践が他にある場合は、それらについても知りたいと思います。

115
Alex Payne

これは素晴らしい質問です!これが最初のカットです。

複数のレベルでログを記録できる(例:デバッグ、警告など)。

hslogger は最も一般的なロギングフレームワークです。

プログラムが実行している作業の種類とその作業にかかる時間に関するメトリック/統計を収集して共有できるようにします。理想的には、収集されたメトリックは、Gangliaなどの一般的に使用されている監視ツールと互換性のある形式で使用できるか、またはそのように変更することができます。

標準化されたレポートツールについては知りませんが、+RTS -sストリームから(またはプロファイリング出力フラグを介して)レポートを抽出することは、以前から行っていました。

$ ./A +RTS -s
64,952 bytes allocated in the heap
1 MB total memory in use
 %GC time       0.0%  (6.1% elapsed)
 Productivity 100.0% of total user, 0.0% of total elapsed

これも機械可読形式で取得できます。

$ ./A +RTS -t --machine-readable

 [("bytes allocated", "64952")
 ,("num_GCs", "1")
 ,("average_bytes_used", "43784")
 ,("max_bytes_used", "43784")
 ,("num_byte_usage_samples", "1")
 ,("peak_megabytes_allocated", "1")
 ,("init_cpu_seconds", "0.00")
 ,("init_wall_seconds", "0.00")
 ,("mutator_cpu_seconds", "0.00")
 ,("mutator_wall_seconds", "0.00")
 ,("GC_cpu_seconds", "0.00")
 ,("GC_wall_seconds", "0.00")
 ]

理想的には、ソケットを介して実行中のGHCランタイムに接続し、これらのGC統計をインタラクティブに見ることができますが、現在のところそれは非常に簡単ではありません(「rts/Stats.h」インターフェースへのFFIバインディングが必要です)。 ThreadScope を使用してプロセスにアタッチし、GCとスレッドの動作を監視できます。

同様のフラグは、ログに記録された増分 time および space プロファイリングで使用でき、監視に使用できます(たとえば、これらの graphs は増分的に構築できます)。

hpcTixタイプを介してプログラムの実行に関する多くの統計を収集し、人々は 書かれたツール をタイムスライスでログに記録しますどのコードが実行されているか。

プログラムを再起動せずに、実行中のプログラムで構成されたプロパティを更新できるシステムを介して、理想的には構成可能にする。

これにはいくつかのツールが利用できます。xmonadスタイルの状態の再読み込みを行うことができます。または plugins *パッケージまたは hint を使用してコードのホットスワップに移動します。これらのいくつかは他のものより実験的です。

再現可能な展開

Galoisは最近リリースされた cabal-dev であり、これは再現可能なビルドを行うためのツールです(つまり、依存関係のスコープと制御が行われます)。

54
Don Stewart
  • 構成に関しては、ConfigFileが私のプロジェクトに役立つことがわかりました。本番環境のすべてのデーモンに使用します。自動的には更新されません。
  • 私は環境全体(ローカル、開発、同僚ローカル)で再現可能なビルドを作成するためにcabal-devを使用します。本当にcabal-devは、特に、プロジェクトディレクトリ内のローカルのパッチされたバージョンのライブラリをサポートする機能のために不可欠です。
  • それが価値があるもののために、私はxmonadスタイルの状態のリロードで行きます。 Haskellの純度はこれを簡単にします。移行は問題ですが、とにかく問題です。 IRCdのhspluginsとヒントを試してみましたが、前者の場合はGHCランタイムの問題があり、後者の場合はセグメンテーション違反がありました。私は後の検死のためにブランチをGithubに残しました: https://github.com/chrisdone/hulk

ConfigFileの例:

# Default options
[DEFAULT]
hostname: localhost
# Options for the first file
[file1]
location: /usr/local
user: Fred
9

私はドンが言ったすべてをエコーし​​、いくつかの一般的なアドバイスを追加します。

たとえば、次の2つの追加のツールとライブラリを検討する必要があります。

  • QuickCheck プロパティベースのテスト用
  • hlint-Wallの拡張バージョンとして

これらはどちらもコード品質を対象としています。

コーディング慣行として、レイジーIOは避けてください。ストリーミングIOが必要な場合は、 enumerator などの反復ライブラリのいずれかを使用します。 Hackage を見ると、http要求に列挙子スタイルを使用するhttp-enumeratorのようなライブラリが表示されます。

ハッカーでライブラリを選択することに関しては、何かに依存しているパッケージの数を調べると役立つことがあります。ハッキングを反映したこのWebサイトを使用できるパッケージの逆依存関係を簡単に確認できます。

アプリケーションが多くのリクエストを処理するWebサーバーのようにタイトなループを実行することになる場合、遅延はスペースリークの形で問題になる可能性があります。多くの場合、これは適切な場所に厳密性注釈を追加することの問題です。プロファイリング、経験、リーディングコアは、この種の問題に対抗するために私が知っている主要なテクニックです。私が知っている最良のプロファイリングリファレンスは 第25章Real-World Haskell です。

9
Jason Dagit