今朝設定した独自ドメイン設定を解除した。
はてなブログの仕様を全然理解しておらず、独自ドメインとはてなブログのサブドメインは両立するものだと思っていた。
が、独自ドメインを設定したらサブドメインへのアクセスはいい感じに独自ドメインにリダイレクトされた。
自分は *.hatenablog.com を気に入っているので他のサイトでのプロフィールに設定するURLは https://koudenpa.hatenablog.com/ のままだと思うけれど、こういう仕組みを体験するのは好きだ。
自分の嗜好は上記な感じなので、記念のスクリーンショットだけとって独自ドメイン設定を解除（CNAMEレコードを削除することで誘発）した。
そのうち *.hatenablog.com に戻るだろう。
以下記念の🦐デンス。
続きを読む世の中の流れに従って自分のID名の .dev ドメインを取得して、このブログに設定した。
https://blog.koudenpa.dev/ でもこのブログを見られるようになるはず。
DNSとはてなブログの設定をした後はDNS設定の伝播や、はてなブログでの証明書発行・設定を待てばいい。
（この記事を公開したタイミングではまだ発行されていないけれどそのうち発行されるだろう）
自分は *.hatenablog.com を気に入っているので他のサイトでのプロフィールに設定するURLは https://koudenpa.hatenablog.com/ のままだと思うけれど、こういう仕組みを体験するのは好きだ。
追記：すぐ解除した。
NuGetは.NET向けのパッケージ管理ツールで、事実上C#言語向けのライブラリが取り扱われていると考えれば良い。
現状の.NETにはざっくりWindows向けの.NET Framework、クロスプラットフォームの.NET Core、それら共通のAPIである.NET Standardがあり、新規に何かしらのライブラリを作成するのなら.NET Standardで作成しておけば概ねどのプラットフォームの.NETアプリケーションでも活用できる。
関係性はMSDNの記事（.NET Standard - .NET Core と .NET Standard の分かりやすい解説）にもまとめられている。
というわけで、先日Mackerelアドベントカレンダーで試していたApp MetricsのメトリクスをMackerelの投稿するReporterをパッケージに切り出した。
まだ切り出して独立したパッケージになっただけで、メトリクスのフォーマットや、投稿にまつわる機能も弱々なので、暇を見て自分がホスティングしているアプリケーションからのレポートをできるくらいにはしたいと考えている。
とはいえ、まずはNuGetパッケージデビュー成功。
作成、公開にあたっては以下のドキュメントを見れば良い。プラットフォーム毎にページが別れているが、.NET Standardのページへの誘導リンクはページにあるようなので、そちらを当たるべし。
npmやNuGetパッケージを公開してみて、使われるかどうかはともかく、公開すること自体にはそれほど敷居の高さがないと感じる。
皆さんも是非どうぞ。
Mackerel Advent Calendar 2018 - Qiita の2日目の記事は以下のようなものでした。
かっこいい。Javaうらやましい。.NET向けに同様な物はないかな？ とググったところ App Metrics というメトリック収集ライブラリがありました。
公式には GrafanaCloud, Prometheus, Elasticsearch, Graphite などがサポートされているようです。
サードパーティで Datadog向けのフォーマッター もありました。
「こいつは面白そうだ」ということで、Mackerelにもメトリクスをレポートしてみました。
続きを読むASP.NET Core では ConfigurationBuilder を使用してアプリケーションの設定を構成する。
ただ、あまりこれを自分で呼び出すことはなく、大体はデフォルト構成で済んでしまう。 その場合はいい感じに構成される。
特別な事情があって自分で構成する場合は、構成メソッドの呼び出しに注意する。 同一のキーの設定値があった場合、後に呼び出した構成メソッドで値が上書きされていく。
私はこのような順で構成し、設定ファイル（ appsettings.json ）のダミー値が採用されました。
var config = new ConfigurationBuilder() .AddCommandLine(args) .AddEnvironmentVariables() .SetBasePath(Directory.GetCurrentDirectory()) .AddJsonFile("appsettings.json", optional: true, reloadOnChange: false) .Build();
実行時引数 ＜ 環境変数 ＜ 設定ファイル の順（強さ）で適用される。 逆だろ！ 普通！！
尚、無意識に使うASP.NET Coreのデフォルト構成はこのような感じでした。 完璧ですね。
.ConfigureAppConfiguration((hostingContext, config) =>
{
var env = hostingContext.HostingEnvironment;
config.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true);
if (env.IsDevelopment())
{
var appAssembly = Assembly.Load(new AssemblyName(env.ApplicationName));
if (appAssembly != null)
{
config.AddUserSecrets(appAssembly, optional: true);
}
}
config.AddEnvironmentVariables();
if (args != null)
{
config.AddCommandLine(args);
}
})
ドキュメントに解説もあります。
ASP.NET Core の Web ホスト | Microsoft Docs
次の順序でアプリの構成を読み込みます。 - appsettings.json。 - appsettings.{Environment}.json。 - エントリ アセンブリを使用して Development 環境でアプリが実行される場合に使用されるシークレット マネージャー。 - 環境変数。 - コマンド ライン引数。
このBlogでは何度も書いていますが、みなさん「ドキュメントはしっかり読みましょう」。それでは。
元々はよい感じに試行を行って『Swagger で広がる Mackerel の世界』のような景気の良いタイトルにしようと思ったのですが、なかなか辛みもあったので弱気なタイトルになりました。本記事は Mackerel Advent Calendar 2018 の4日目の記事です。
さて、Mackerelは近年のSaaSでは標準装備となっているHTTPで呼び出せるAPIの提供が行われています。
Mackerelの機能は公式の mackerel-agent も含めてほぼすべてがこのAPIを活用しています。
（Webコンソールは違う様子です。そもそも認証がAPI Keyではないですからね）
このHTTPで呼び出せるAPIには定義の仕様が存在しており、その中の一つがSwaggerです。 現在はSwaggerの後継のOpenAPI Specificationが最新なのですが、周辺エコシステムの整備状況から2018年末現在ではSwaggerを使用するのが現実的な状況です。
さて、そのSwaggerによるMackerel APIの仕様定義があるとどうなるのか？ を見てみたいと思います。
サンプルはSwaggerを良い感じに活用している気がする Azure の Logic Apps です。
定義は自分がMackerelを使うときのサンプルにしている『アラートの数をサービスメトリックに投稿する』事ができる最低限のAPIに対して行いました。
open-api-spec-sandbox/mackerel-api.yml at master · 7474/open-api-spec-sandbox · GitHub
続きを読む月末ですね。
Mackerelアドベントカレンダーが明日から始まりますが、この試行は月末に価値があるので自称0日目の記事として書きます。
さて、みなさん、勤怠の記録は毎日つけていますか？ 自分はまぁ、言わぬが華です。
Google MapのLogで毎日何時頃にオフィスにIn/Outしているのかを月末にチェックしているような人もいるようです。面倒くさいですね。
さて、Mackerelユーザーの作業用端末には当然 mackarel-agent が入っています。であるならば、閉じたアラートも取れるようになったMackerelのAPIでその電源On/Off時間（デフォルトで構成される connectivity アラート！）を得ることができます。これは相当に正確な出退勤時間ではないでしょうか？
前置きが長いですね。試しました。
mkr コマンドと jq コマンドの合わせ技です。
$ HOSTID=YOURHOSTID $ mkr alerts -w | jq -r ".[] | select((.type == \"connectivity\") and (.hostId == \"$HOSTID\")) | [(.openedAt|tonumber|.+32400|todate), (.closedAt|tonumber|.+32400|todate)] | @csv" "2018-11-30T09:52:03Z","2018-11-30T09:55:26Z" "2018-11-30T06:31:03Z","2018-11-30T09:45:50Z" "2018-11-30T04:54:03Z","2018-11-30T06:25:14Z" "2018-11-30T01:18:03Z","2018-11-30T04:48:36Z" "2018-11-29T23:30:04Z","2018-11-30T01:12:17Z" "2018-11-29T21:42:03Z","2018-11-29T23:24:23Z" "2018-11-29T20:37:04Z","2018-11-29T21:36:23Z" "2018-11-29T19:59:04Z","2018-11-29T20:31:22Z" "2018-11-29T19:43:04Z","2018-11-29T19:43:23Z" "2018-11-29T19:24:03Z","2018-11-29T19:26:35Z" "2018-11-29T13:21:03Z","2018-11-29T13:28:52Z" "2018-11-29T11:11:03Z","2018-11-29T11:13:08Z" "2018-11-29T10:04:03Z","2018-11-29T10:09:36Z" "2018-11-28T21:02:03Z","2018-11-29T09:46:59Z" "2018-11-28T18:20:03Z","2018-11-28T19:01:07Z"
結果を見てみましょう。
"2018-11-30T09:52:03Z","2018-11-30T09:55:26Z" <- 身に覚えがない "2018-11-30T06:31:03Z","2018-11-30T09:45:50Z" <- Close=出勤時間 "2018-11-30T04:54:03Z","2018-11-30T06:25:14Z" <- なにこれ "2018-11-30T01:18:03Z","2018-11-30T04:48:36Z" <- なにこれ "2018-11-29T23:30:04Z","2018-11-30T01:12:17Z" <- なにこれ "2018-11-29T21:42:03Z","2018-11-29T23:24:23Z" <- なにこれ "2018-11-29T20:37:04Z","2018-11-29T21:36:23Z" <- Open=退勤時間（社内で懇親会していたので少し遅い "2018-11-29T19:59:04Z","2018-11-29T20:31:22Z" <- 階移動時のWi-Fi切れ "2018-11-29T19:43:04Z","2018-11-29T19:43:23Z" <- 接続切れすぎ "2018-11-29T19:24:03Z","2018-11-29T19:26:35Z" <- 接続切れすぎ "2018-11-29T13:21:03Z","2018-11-29T13:28:52Z" <- 覚えてない "2018-11-29T11:11:03Z","2018-11-29T11:13:08Z" <- 覚えてない "2018-11-29T10:04:03Z","2018-11-29T10:09:36Z" <- 覚えてない "2018-11-28T21:02:03Z","2018-11-29T09:46:59Z" <- 綺麗に勉強会終了〜出勤時刻が出てる！ "2018-11-28T18:20:03Z","2018-11-28T19:01:07Z" <- Open=退勤、Close=勉強会場でWi-Fi接続、この日にエージェント入れた
うーむ。微妙。思った以上にノイズが多かったです。
とはいえ、自分にとってはとても参考になる確実なデータを得られました。
今後活用する機会がありそうです。
それでは皆さん、Mackerelと一緒によい社会生活を！