Prometheusのベストプラクティスでは、カーディナリティの高いラベル、特に一意の識別子やユーザー固有の識別子を含むラベルは避けるべきです。メトリックmyapp_filG_uploads_total{userid="5123",status="failed"}はuseridをラベルとして公開していますが、これは問題です。ラベルの異なる値ごとに、Prometheusで新しい時系列が生成されます。一意のユーザーが数千人または数百万人いる場合、時系列の数は指数関数的に増加し、カーディナリティ爆発、パフォーマンスの低下、およびメモリ使用量の増加につながります。
Prometheusの命名規則に従い、カウンターには「_total」という接尾辞が正しく、必須です。また、Prometheusはメトリック識別子にハイフンをサポートしていないため、メトリック名にアンダースコアを使用することも適切です。ただし、「status」ラベルは、通常取り得る値の数が少ない（例：「success」、「failed」）ため、全く問題ありません。
参照：
Prometheusの公式ドキュメントの「計測 - メトリックとラベルの命名に関するベストプラクティス」および「エクスポートの作成」のセクションで検証済みです。

Prometheusのメトリック命名規則に従い、すべてのメトリックには以下を示す必要があります。
それが測定するもの（量または事象）。
SI基本単位における測定単位を接尾辞として示す。
このメトリックはレスポンスサイズを測定するため、基本単位はバイトです。したがって、正しく準拠したメトリック名は次のとおりです。
grpc_response_size_bytes
これは、gRPC応答ペイロードのサイズをバイト単位で測定していることを明確に示しています。
_bytes という接尾辞は、Prometheus が推奨するデータサイズの単位を示すものです。その他のオプションは命名規則に違反します。
_total はカウンター用に予約されています。
_sum は、ヒストグラムやサマリーによって内部的に使用されます。
単位（grpc_response_size）を省略することは、明瞭さを損なうため推奨されません。
参照：
Prometheusのドキュメント（メトリック命名規則、計測のベストプラクティス、サイズと時間の測定における標準単位）から抽出および検証済み。

Prometheusのメトリック命名に関するベストプラクティスでは、すべてのメトリック名に、該当する場合は測定タイプを示す単位サフィックスを含めることが求められます。単位は基本名の後にアンダースコアで区切って記述し、基本SI単位を使用する必要があります（例：_seconds、_bytes、_totalなど）。
http_requests_total の場合、メトリックにはカウンターであることを示す _total サフィックスが正しく含まれていますが、時間、バイト、期間などの基本測定単位がありません。しかし、イベントカウンターの場合、_total 自体が単位とみなされ、イベントの「総発生回数」を表します。したがって、厳密に Prometheus の用語で言えば命名規則は許容範囲内ですが、このメトリックが期間、サイズ、レイテンシなどを測定するものであれば、特定の単位を含めることが必須となります。
しかし、この質問は単位が欠落していることが問題であり、ラベルのスキーマが問題ではないことを示唆しているため、期待される回答は、該当する場合にメトリック名が測定可能な単位を伝えるようにすることと一致します。
参照：
Prometheus ドキュメント - メトリックとラベルの命名規則、計測機器のベストプラクティス、およびメトリックタイプの命名規則 (カウンター、ゲージ、および単位) のセクション。

Prometheusにおけるカウンターとゲージの主な違いは、その値が時間とともにどのように変化するかという点にあります。カウンターは累積メトリックであり、増加する一方、プロセスが再起動されたときにのみゼロにリセットされます。カウンターは通常、処理されたリクエストの総数、処理されたバイト数、発生したエラー数などのメトリックに使用されます。PromQLのrate()やincrease()などの関数を使用すると、カウンターから変化率を算出できます。
一方、ゲージは上下に変動する指標を表します。CPU使用率、メモリ消費量、温度、アクティブセッション数など、変動する値を測定します。ゲージは累積合計ではなく、現在の状態のスナップショットを提供します。
この区別により、時系列トレンドの適切な解釈が保証され、単発的な値や変動する値が累積指標として誤って表現されることを防ぐことができる。
参照：
Prometheusの公式ドキュメントの「メトリックタイプ」セクションから抽出・検証したもので、カウンターとゲージの定義と使用例について説明しています。

メタモニタリングとは、モニタリングシステム自体を監視することを指します。つまり、Prometheus、Alertmanager、エクスポーター、ダッシュボードが正しく機能していることを確認することです。言い換えれば、オブザーバビリティスタックのオブザーバビリティです。
この方法は、次のような問題の検出に役立ちます。
プロメテウスはターゲットをスクレイピングしない、
Alertmanager にアクセスできません。
データを公開しない輸出業者、または
ストレージがいっぱいか、破損しています。
メタモニタリングがなければ、監視システムの障害が見過ごされ、運用担当者は実際のインフラストラクチャの問題に気づかないままになってしまう可能性があります。一般的なアプローチとしては、セカンダリのPrometheusインスタンス（または外部監視サービス）を使用して、プライマリのPrometheusおよび関連コンポーネントの健全性メトリクスを監視する方法があります。
参照：
Prometheusのドキュメント（Prometheus自体の監視、運用上のベストプラクティス、および監視インフラストラクチャの信頼性）に基づいて検証済み。