
米ワシントン大学や米ロチェスター大学などに所属する研究者らが発表した論文「Resolving the mysteries of brain clearance and immune surveillance」は、脳の老廃物排出と免疫監視に関する最新の知見をまとめた報告だ。
睡眠中に「脳内のごみ」を活発に洗い流していた 掃除が不十分だと認知症リスク増 米国チームが発表:Innovative Tech - ITmedia NEWS
臓器には老廃物を運び出すリンパ管が張り巡らされているが、脳の内部にはリンパ管が存在しない。では脳はどのようにして代謝老廃物を処理しているのか。この問いに答えたのが、2012年に提唱された「グリンパティック系」だ。
睡眠中に「脳内のごみ」を活発に洗い流していた 掃除が不十分だと認知症リスク増 米国チームが発表:Innovative Tech - ITmedia NEWS
注目は、この排出システムが睡眠中に活性化すること。マウスの研究では、睡眠時のβアミロイド(アルツハイマー病の原因物質の1つ)の除去速度は覚醒時の約2倍に達した。睡眠中は脳細胞の隙間が広がり、液体が流れやすくなることがその理由の一つだ。
睡眠中に「脳内のごみ」を活発に洗い流していた 掃除が不十分だと認知症リスク増 米国チームが発表:Innovative Tech - ITmedia NEWS
さらに深い睡眠(ノンレム睡眠)の間には、脳幹の青斑核からノルエピネフリンが周期的に放出され、これが血管を大きく収縮・拡張させて脳脊髄液の流入を促す。
睡眠中に「脳内のごみ」を活発に洗い流していた 掃除が不十分だと認知症リスク増 米国チームが発表:Innovative Tech - ITmedia NEWS
⇧ 睡眠中に「βアミロイド」が除去される話は前々から言われていたと思うが...
ちなみに、
世界的にみて日本人の睡眠時間は短い傾向にあります。2021年に発表された経済協力開発機構(OECD)の平均睡眠時間の各国比較によると、先進国を中心にした世界33カ国のうち日本はもっとも短く、1日あたり7時間22分でした。OECD加盟国の中で睡眠時間が一番長い米国は8時間51分で、日本人よりも1時間半も長く睡眠をとっていることが明らかになりました。
⇧ 上記によると、「日本」は「睡眠時間」が短いらしいので、他の国に比べて「βアミロイド」の除去が不十分な状態が継続された状態で生活していることになることから、「認知症」のリスクも大きいということですかね...
発給の上に、長時間労働せざるを得ない業務量を負担させられた挙句、睡眠時間を減らすことを強いられ、労働から解放される頃には「認知症」になるかもしれないって、絶望的な仕組みですな...
何と言いますか、映画『悪い奴ほどよく眠る(監督:黒澤明)』を彷彿とさせる状況でありますな...
Zabbix APIでPaginationはサポートされていないので自前で実装する必要があるという衝撃...
なかなかの衝撃なのだが、
⇧「Zabbix API」は「Pagination」をサポートしていないらしい...
噓やろ...
21世紀も最初の四半世紀を終えたというのに、「Zabbix API」は「Pagination」をサポートしていない...
噓やろ...
「Zabbix」が公開されて、25年は経とうとしているのに、「Zabbix API」は「Pagination」をサポートしていない...
歴史
1998年、ZabbixはAlexei Vladishev(アレクセイ・ウラジシェフ)によって、ある銀行の社内プロジェクトとして開発された。
2001年、GPLの元一般に公開された。
2004年、最初の安定版バージョン1.0がリリースされた。
2006年、バージョン1.1がリリースされ、2007年に1.4、2008年に1.6、2009年には1.8がリリースされた。
2012年、初の長期サポート版(Long Term Support)である2.0LTSがリリースされた。
2016年に3.0 LTS、2018年に4.0 LTS、2020年に5.0 LTS 、2022年に6.0 LTS、 2024年に7.0 LTS がリリースされている。
噓やろ...
あまりの衝撃に3回同じことを呟いてしまったのだが...
そして、「Is there Pagination with API ? - ZABBIX Forums」の質問については、回答も無いですしな...
兎にも角にも、2014年1月28日に要望は上がっているようなのだが、12年が経過しようとしているのに何の進展も無い気配なのが絶望的なのだが...
そもそも、
Zabbix はアレクセイ・ウラジシェフ(Alexei Vladishev)によって作られた、ネットワーク管理ソフトウェアである。様々なネットワークサービス、サーバ 、その他のネットワークハードウェアのステータスを監視・追跡できる。現在はウラジシェフが設立したZabbix社によって開発が継続されている。
⇧ 上記にあるように、何某の「デバイス」の「状態」の監視・追跡を目的としているのならば、対象が膨大な数になることも想定できたような気がするのだが...
「変更容易性」が考慮されていないということなんだろうか...
まぁ、「Zabbix」で利用される「データベース」の「テーブル」の「設計」の「ドキュメント」などが見当たらない時点で、「変更容易性」などは一切考慮されていなかったのだとは思われますが...
ちなみに、今回は、
In Database
Pagination is an approach used to limit and display only a part of the total data of a query in the database. Instead of showing hundreds or thousands of rows at the same time, the server is requested only one page (a limited set of rows, per example only 10 rows), and the user starts navigating by requesting the next page, and then the next one, and so on. It is very useful, specially in web systems, where there is no dedicated connection between the client and the server, so the client does not have to wait to read and display all the rows of the server.
⇧ 上記にあるように、「データベース」における「Pagination」の話。
ザックリ言うと、大量のレコードの内のどの範囲を取得するかを指定する機能のこと。
で、「クライアント」側が「Web画面」とかだと、
In web browsers
Electronic pages displayed on a web browser are often called web pages, regardless of whether they are accessed online via a web server on the World Wide Web, or stored locally offline. More accurately, such documents are named by the markup language that makes them displayable via a web browser, e.g. "HTML page".
![]()
Example of a pagination as part of a user interface of a web page
⇧ 上記のような感じで「次のページ」的な「UI(User Interface)」が表示される。
勿論、「フロントエンド」側の実装も必要になるのだが。
まぁ、「サーバーサイド」側で「データ」を取得して「フロントエンド」側に返してあげないことには、「フロントエンド」側の「Pagination」の実装ができないのだが...
で、話を「Zabbix API」に戻すと、改めて「Pagination」がサポートされていないという衝撃に震えることになる...
信じられないのは、「Zabbix」の「Web画面」は「Pagination」に対応しているのに、「Zabbix API」は「Pagination」に対応していないのである...
ネットの情報を漁っていたところ、
■https://support.zabbix.com/si/jira.issueviews:issue-html/ZBXNEXT-2132/ZBXNEXT-2132.html
from zabbix_utils import ZabbixAPI
// ... login stuff
def get_zabbix_hosts():
zabbix_hosts_ids = zabbix.host.get(
output="hostid",
evaltype=0,
tags=[
{
"tag": "cmdb_id",
"operator": 4
}
]
)
chunk_size = 1000
chunks = [chunk['hostid'] for chunk in zabbix_hosts_ids]
zabbix_hosts = []
for i in range(0, len(chunks), chunk_size):
chunk = chunks[i:i + chunk_size]
zabbix_hosts += zabbix.host.get(hostids=chunk,
selectMacros="extend",
selectTags="extend",
selectHostGroups="extend",
selectParentTemplates="extend",
selectInterfaces="extend")
return zabbix_hosts

⇧ 上記サイト様にありますように、自前で「Pagination」を実装する必要があるらしいという...
悲報...
⇧ 上記の情報が正しいとすると、「Zabbix API」は最大で扱える「レコード」が「10万」までらしい。
なので、管理している「レコード」が「10万」を超えている場合、「10万」以降の「レコード」に対しては「Pagination」を実現できないということになる。
と言うのも、「OFFSET」のような取得開始位置を指定できないっぽいので...
「要件」として、扱う「レコード」が「10万」を超えるのであれば、「Zabbix API」を使わずに、直に「Zabbix API」が参照する「テーブル」に対して実行する「SQL」を組み立てる必要があるのだが、そのためには、
⇧ 上記の時に触れたのだが、「Zabbix API」が実施している「SQL」の「クエリ」を確認して対象の「テーブル」を特定する必要がありますと...
いやはや、「Zabbix API」の「設計」が破綻しているとしか思えないのよ...
独自のカスタマイズした機能の実装は、「マイグレーション」の際に「技術的負債」になる「リスク」があるので、できれば避けたいのだが、
- 「Zabbix API」が「Pagination」に対応する気が無い
- 「レコード」が10万件を超える
といった条件の場合、独自のカスタマイズした機能の実装をせざるを得ないということか...
12年が経とうとしているのに、進展が無いところを見ると、最早、「Zabbix」というプロダクトは「リファクタリング」が不可能な手に負えない状態になっているということなんだろうか...
どう考えても、「Zabbix API」の「Pagination」の機能は対応すべき「優先順位」が高い気がするんだが...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
