<Endpoint>/Users
 -H"Authorization: Bearer <Token>"
 -H"Content-type: application/json" -d'
    {  "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
      ],
"userName": "EmailAddress",
"displayName": "displayName",
      "name": {
        "familyName": "familyName",
        "givenName": "givenName"
      },
    "active": true
}'

グループ作成

<Endpoint>/Groups
 -H"Authorization: Bearer <Token>"
 -H"Content-type: application/json" -d'
{"schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:Group"
      ],
      "displayName": "GroupName",
      "members": []
}'

グループメンバー更新(メンバー一覧をreplaceする。)

グループ情報を拾っても、現在のメンバー一覧が取得できないため、メンバー一覧をreplaceでまるっと入れ替える。

<Endpoint>/Groups/<group-id>
-XPATCH
 -H"Authorization: Bearer <Token>"
 -H"Content-type: application/json" -d'
{
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ],
  "Operations": [
    {
      "op": "replace",
      "path": "members",
      "value": [
        { "value": "<User-id>"},
        { "value": "<User-id>"},
        { "value": "<User-id>"},
        { "value": "<User-id>"}
      ]
    }
  ]
}'

2020-09-16

Prometheusのデータ長期保存にVictoriaMetricsを使う。

概要

Prometheus2.0にて、 remote write という、Prometheusで収集したデータを別のストレージにも書き込む機能ができています。

InfluxdbやThanosやM3など、remote write先はいくつかありますが、

Measuring vertical scalability for time series databases in Google Cloud | by Aliaksandr Valialkin | Medium

を読んだりして、VictoriaMetricsがよさそうだなと思い、導入した話

VictoriaMetrics

VictoriaMetrics | The best long-term remote storage

VictoriaMetricsの特徴はいくつかありますが、Prometheusのクエリ言語がそのままつかえる、というのがあります。

つまり、Grafanaなどで参照する先をPrometheusからVictoriaMetricsに切り替えられるということです。

これの何がいいかというと、Prometheusはデータの収集にのみ焦点を当てることができるということです。

また、VictoriaMetricsは、vmagent、vmalertなど、いくつかの周辺ツールも用意しています。

vmagentはPrometheusの設定ファイルを読んで、Proemtheusと同じようにデータを収集し、VictoriaMetricsにデータを送ることができます。

vmalertはPrometheusのアラート発砲と同じ機能があります。Alertmanagerと組み合わせ、アラート管理が行えます。

Prometheusを、さらに細かく機能ごとに分割したもの。というイメージです。

Prometheusがデータの永続化に興味がないのに対し、VictoriaMetrics can be used as long-term storage とうたっているように、長期間データを保存することが年頭におかれています。先に示したmediumの記事に書いてある中でもストレージ使用量はInfluxdbの半分程度です。

VictoriaMetircsにはclusterバージョンもありますが、ここでは触れません。

Prometheus から VictoriaMetricsにデータを送信する

これはとても簡単で、Prometheusのremote_rwite設定に、 VictoriaMetricsをセットアップしたノードを記載するだけです。

PrometheusとVictoriaMetricsでのデータ利用量比較

私の見ている環境では、Prometheus の標準設定 15日分保存で42GB程度のストレージを消費している環境で、同じくVictoriaMetricsへ15日分転送が終わった段階で、7.5GB程度のストレージ消費でした。

だいたい1/5 - 1/6 程度のサイズで済んでいます。つまり、同程度のストレージを用意すると、それだけで3か月分保存ができるということです。

また、Grafanaをたくさんの人が開いていると、クエリが処理しきれいず、Prometheusでのデータ収集が止まるということが度々起こっていましたが、VictoriaMetricsを利用することにより、データの取得元をVictoriaMetircsへ変更することができ、 Proemtheusのデータ収集が止まるということが起こらなくなりました。

これは大きな利点でした。

結論

VictoriaMetricsを利用して Prometheus+Grafanaの環境がとてもよくなりました。やっぱり長期保存、PromQL対応は良かったです。

なんかいろいろと

てきとう

gitlab-runner 11.11 での仕様変更ではまった話

何が起きたのか

回避

この問題のMerge Requestへの link

AWS SSO のユーザをSCIMでプロビジョニングする。

事前準備

ユーザ作成