Dear Wikitech-l community,
Wikimania 2025 is just around the corner! From August 6–9 in Nairobi, Kenya (with a pre-conference and Hackathon on August 5), we’ll be celebrating 20 years of Wikimania with the theme: Wikimania@20: Inclusivity. Impact. Sustainability.
This is your opportunity to shape the conversation! The Call for Program Proposals is ongoing until March 31. We’re seeking your innovative ideas to explore how technical solutions and advancements can drive inclusivity, amplify impact, and promote sustainability across Wikimedia projects.
Here are some examples of the technical session ideas you could submit:
● Developing tools to enhance accessibility for contributors with specific needs.
● Exploring how AI can support content translation and bridge knowledge gaps.
● Showcasing innovative approaches to improve sustainability in Wikimedia's infrastructure.
● Discussions on improving software usability for global, diverse communities.
Your contributions will enrich this celebration of community and innovation. Proposals can be presented in any mode:
● Remotely from the comfort of your home or workplace
● As a pre-recorded presentation.
● Or, join us in person in Nairobi!
Submit your proposals now at: https://wikimania.wikimedia.org/wiki/2025:Program
For any questions, suggestions, or assistance, feel free to contact us at wikimania(a)wikimedia.org . Our dedicated team of volunteers is here to support you.
Let’s make Wikimania 2025 an unforgettable showcase of your ingenuity and collaborative spirit! We look forward to seeing your contributions that highlight the continued impact of technology at this landmark event.
Warm regards,
Butch Bustria
https://wikimania.wikimedia.org/wiki/2025:Organisers
1. Gia Công Thực Phẩm Chức Năng Là Gì?
Gia công thực phẩm chức năng (TPCN) là quá trình sản xuất sản phẩm theo yêu cầu của doanh nghiệp, thương hiệu hoặc cá nhân, nhưng do một nhà máy chuyên về gia công thực hiện. Nhà máy này sẽ chịu trách nhiệm từ khâu nghiên cứu công thức, lựa chọn nguyên liệu, sản xuất, kiểm nghiệm, đóng gói cho đến khi sản phẩm hoàn chỉnh, sẵn sàng đưa ra thị trường.
See source: https://chietxuatduoclieu.com/gia-cong-thuc-pham-chuc-nang
Gia công TPCN giúp các doanh nghiệp tối ưu hóa chi phí sản xuất, tận dụng công nghệ tiên tiến và đảm bảo sản phẩm đạt chuẩn chất lượng mà không cần đầu tư trực tiếp vào dây chuyền sản xuất.
2. Các Hình Thức Gia Công Thực Phẩm Chức Năng
Có nhiều hình thức gia công TPCN tùy theo nhu cầu của doanh nghiệp, bao gồm:
✔ Gia công trọn gói: Nhà máy chịu trách nhiệm từ A-Z, bao gồm nghiên cứu công thức, sản xuất, đóng gói và hỗ trợ pháp lý.
✔ Gia công theo công thức có sẵn: Doanh nghiệp cung cấp công thức, nhà máy chỉ thực hiện sản xuất.
✔ Gia công nguyên liệu thô: Nhà máy chỉ xử lý và chiết xuất nguyên liệu, doanh nghiệp tự sản xuất thành phẩm.
✔ Gia công theo thương hiệu riêng (OEM - Original Equipment Manufacturer): Nhà máy sản xuất sản phẩm theo yêu cầu của doanh nghiệp nhưng mang thương hiệu riêng của doanh nghiệp đó.
3. Những Lưu Ý Khi Gia Công Thực Phẩm Chức Năng
✅ Lựa chọn nhà máy đạt chuẩn GMP
GMP (Good Manufacturing Practice) là tiêu chuẩn quan trọng đảm bảo sản phẩm được sản xuất trong điều kiện an toàn, vệ sinh và đạt chất lượng cao. Một nhà máy đạt chuẩn GMP sẽ giúp đảm bảo sự an toàn và hiệu quả của sản phẩm.
✅ Chọn nguyên liệu chất lượng, rõ nguồn gốc
Thực phẩm chức năng thường chứa các thành phần như vitamin, khoáng chất, thảo dược, collagen, probiotic... Do đó, việc chọn nguyên liệu chất lượng, có chứng nhận an toàn thực phẩm, tránh tạp chất hoặc hóa chất độc hại là rất quan trọng.
✅ Kiểm định chất lượng nghiêm ngặt
Các sản phẩm trước khi ra thị trường cần được kiểm định để đảm bảo đạt tiêu chuẩn vệ sinh an toàn thực phẩm, hàm lượng hoạt chất đúng quy định và không chứa tạp chất gây hại.
✅ Đăng ký giấy phép lưu hành đầy đủ
Thực phẩm chức năng trước khi phân phối cần có giấy phép của Bộ Y tế và các cơ quan chức năng liên quan. Doanh nghiệp cần kiểm tra và đảm bảo rằng sản phẩm của mình được cấp phép đầy đủ.
✅ Thiết kế bao bì và thương hiệu hấp dẫn
Một sản phẩm chất lượng đi kèm với bao bì chuyên nghiệp sẽ giúp tạo dựng lòng tin với khách hàng và gia tăng giá trị thương hiệu trên thị trường.
4. Xu Hướng Gia Công Thực Phẩm Chức Năng Hiện Nay
Hiện nay, xu hướng sản xuất thực phẩm chức năng đang tập trung vào các sản phẩm có nguồn gốc tự nhiên, hữu cơ, không chứa hóa chất độc hại, thân thiện với sức khỏe như:
✔ Thực phẩm bổ sung hỗ trợ miễn dịch: Như sản phẩm từ đông trùng hạ thảo, nhân sâm, nấm linh chi...
✔ Thực phẩm bổ sung sắc đẹp: Collagen, Glutathione, chiết xuất cà chua trắng, vitamin C tự nhiên...
✔ Sản phẩm hỗ trợ tiêu hóa: Men vi sinh, chất xơ hòa tan, probiotic...
✔ Sản phẩm hỗ trợ giảm cân: Tinh bột nghệ, chiết xuất trà xanh, L-Carnitine...
Kết Luận
Gia công thực phẩm chức năng là giải pháp tối ưu giúp doanh nghiệp đưa sản phẩm chất lượng ra thị trường một cách hiệu quả. Tuy nhiên, để đảm bảo thành công, doanh nghiệp cần lựa chọn nhà máy gia công uy tín, tuân thủ các tiêu chuẩn chất lượng và có chiến lược phát triển sản phẩm phù hợp với xu hướng thị trường.
Source: https://chietxuatduoclieu.com/
1. Giới thiệu về sản xuất cao dược liệu
1.1. Cao dược liệu là gì?
<a href="https://chietxuatduoclieu.com/chiet-xuat-cao-duoc-lieu">Cao dược liệu là dạng chiết xuất cô đặc từ thảo dược</a>, giữ lại các hoạt chất có lợi nhằm ứng dụng trong y học và thực phẩm chức năng. Quá trình sản xuất cao dược liệu giúp tập trung các hợp chất sinh học quan trọng từ nguyên liệu thảo dược, tạo ra sản phẩm có hiệu quả cao hơn so với việc sử dụng dược liệu thô. Cao dược liệu có thể tồn tại ở nhiều dạng như cao lỏng, cao mềm, hoặc cao khô tùy theo mục đích sử dụng và yêu cầu sản phẩm.
Cao dược liệu không chỉ được ứng dụng rộng rãi trong y học cổ truyền mà còn là thành phần quan trọng trong ngành công nghiệp thực phẩm chức năng, mỹ phẩm và dược phẩm. Việc tiêu chuẩn hóa quá trình sản xuất giúp đảm bảo chất lượng đồng nhất, kiểm soát hàm lượng hoạt chất và tránh tạp chất có hại.
1.2. Tầm quan trọng của công nghệ sản xuất
Công nghệ sản xuất đóng vai trò quyết định đến chất lượng, hàm lượng hoạt chất và độ tinh khiết của cao dược liệu, ảnh hưởng trực tiếp đến hiệu quả sử dụng. Nếu quy trình chiết xuất không được tối ưu hóa, hoạt chất có thể bị mất đi hoặc bị biến tính, làm giảm hiệu quả của sản phẩm. Ngược lại, với công nghệ tiên tiến, nhà sản xuất có thể bảo toàn tối đa các hợp chất có lợi, đồng thời loại bỏ tạp chất không mong muốn.
Các phương pháp sản xuất hiện đại như chiết xuất siêu tới hạn, chiết xuất enzyme, hay chiết xuất siêu âm không chỉ giúp tối ưu hiệu suất thu nhận hoạt chất mà còn đảm bảo tính an toàn cho sản phẩm cuối cùng. Ngoài ra, quá trình cô đặc và sấy cũng cần được thực hiện với công nghệ phù hợp để giữ nguyên giá trị sinh học của cao dược liệu, đáp ứng các tiêu chuẩn khắt khe của ngành công nghiệp dược phẩm và thực phẩm chức năng.
2. Các thách thức trong sản xuất cao dược liệu
2.1. Hao hụt hoạt chất trong quá trình chiết xuất
Một trong những thách thức lớn nhất trong sản xuất cao dược liệu là sự hao hụt hoạt chất trong quá trình chiết xuất. Nhiều hoạt chất sinh học trong dược liệu rất nhạy cảm với nhiệt độ cao, dễ bị phân hủy hoặc bay hơi trong môi trường không phù hợp. Ví dụ, các hợp chất dễ bay hơi như tinh dầu hoặc flavonoid có thể mất đi nếu không được chiết xuất bằng phương pháp tối ưu.
Ngoài ra, môi trường kiềm hoặc axit trong quá trình chiết xuất cũng có thể làm biến tính hoặc làm giảm hàm lượng hoạt chất có lợi. Việc sử dụng phương pháp chiết xuất không kiểm soát tốt nhiệt độ hoặc áp suất có thể làm giảm chất lượng sản phẩm. Hơn nữa, trong quy trình sản xuất truyền thống, việc xử lý thủ công không chỉ làm giảm hiệu suất chiết xuất mà còn có nguy cơ làm biến đổi hoạt chất, ảnh hưởng đến tính ổn định và hiệu quả của cao dược liệu.
2.2. Khó khăn trong kiểm soát tạp chất
Một vấn đề khác trong sản xuất cao dược liệu là việc kiểm soát tạp chất. Nếu không có công nghệ lọc và tinh chế phù hợp, cao dược liệu có thể bị lẫn tạp chất từ nguyên liệu đầu vào hoặc từ chính quá trình sản xuất. Điều này không chỉ làm giảm chất lượng sản phẩm mà còn có thể gây ảnh hưởng tiêu cực đến sức khỏe người tiêu dùng.
Một trong những nguy cơ lớn nhất là dư lượng dung môi trong cao dược liệu. Một số phương pháp chiết xuất sử dụng dung môi hữu cơ để thu hoạt chất, nhưng nếu quy trình loại bỏ dung môi không được thực hiện đúng cách, dư lượng còn lại có thể gây ảnh hưởng xấu đến sức khỏe. Ngoài ra, các kim loại nặng, vi khuẩn, nấm mốc hoặc chất bảo quản không phù hợp cũng có thể làm giảm chất lượng của cao dược liệu, đòi hỏi quy trình kiểm tra nghiêm ngặt và công nghệ tinh chế hiện đại để loại bỏ hoàn toàn các tạp chất này.
3. Công nghệ chiết xuất tiên tiến giúp bảo toàn hoạt chất
3.1. Công nghệ chiết xuất bằng dung môi siêu tới hạn (Supercritical Fluid Extraction – SFE)
Công nghệ SFE sử dụng CO₂ siêu tới hạn để chiết xuất hoạt chất từ thảo dược mà không làm biến tính chúng. Ở trạng thái siêu tới hạn, CO₂ có tính chất giống cả khí và lỏng, giúp thẩm thấu sâu vào nguyên liệu và hòa tan các hợp chất mong muốn một cách chọn lọc.
Ưu điểm lớn của phương pháp này là giữ nguyên hương vị, màu sắc và cấu trúc hóa học của dược liệu. Ngoài ra, CO₂ là dung môi sạch, không để lại dư lượng độc hại, giúp sản phẩm đạt tiêu chuẩn an toàn cao.
3.2. Công nghệ chiết xuất bằng enzyme
Công nghệ này sử dụng enzyme sinh học để phá vỡ thành tế bào thực vật, giúp giải phóng hoạt chất một cách hiệu quả mà không cần sử dụng dung môi hóa học. Nhờ đó, công nghệ enzyme đảm bảo an toàn hơn cho người sử dụng và thân thiện với môi trường.
Ngoài ra, phương pháp này còn có thể được điều chỉnh để phù hợp với từng loại dược liệu khác nhau, giúp tối ưu hóa khả năng thu nhận hoạt chất, đồng thời giảm thiểu sự hao hụt hoặc biến tính trong quá trình xử lý.
3.3. Công nghệ chiết xuất siêu âm (Ultrasound-Assisted Extraction – UAE)
Công nghệ UAE sử dụng sóng siêu âm để tạo ra bọt khí vi mô, giúp phá vỡ màng tế bào thực vật một cách nhanh chóng và hiệu quả. Điều này giúp tăng tốc độ chiết xuất, giảm thời gian xử lý và nâng cao hiệu suất thu nhận hoạt chất.
4. Công nghệ cô đặc và sấy hiện đại giữ nguyên hoạt chất
4.1. Công nghệ cô đặc chân không
Công nghệ cô đặc chân không giúp giảm nhiệt độ sôi của dung dịch, giúp bảo toàn các hoạt chất dễ bay hơi và nhạy cảm với nhiệt độ cao. Nhờ vào áp suất thấp, quá trình này tiết kiệm năng lượng và giảm thiểu sự phân hủy nhiệt của hoạt chất.
4.2. Công nghệ sấy phun (Spray Drying)
Sấy phun là phương pháp chuyển dịch chiết thành dạng bột mịn bằng cách phun sương và làm khô nhanh chóng trong luồng khí nóng. Công nghệ này giúp cao dược liệu dễ bảo quản, sử dụng và phân phối. Đặc biệt, phương pháp này giữ được sự ổn định của hoạt chất, tránh hiện tượng kết tụ và không bị ảnh hưởng bởi độ ẩm.
4.3. Công nghệ sấy thăng hoa (Freeze Drying)
Sấy thăng hoa là kỹ thuật đông lạnh nguyên liệu rồi loại bỏ nước bằng phương pháp thăng hoa. Phương pháp này giữ nguyên cấu trúc hoạt chất, bảo toàn màu sắc, hương vị tự nhiên của dược liệu, đồng thời giúp kéo dài hạn sử dụng mà không làm mất đi các hoạt chất quan trọng.
5. Ứng dụng công nghệ nano trong sản xuất cao dược liệu
5.1. Công nghệ nano giúp tăng sinh khả dụng của hoạt chất
Công nghệ nano giúp chia nhỏ hoạt chất thành các phân tử có kích thước siêu nhỏ, giúp chúng dễ dàng thẩm thấu vào cơ thể hơn. Nhờ đó, khả năng hấp thu của cao dược liệu tăng lên đáng kể, đồng thời giảm liều lượng sử dụng mà vẫn đạt hiệu quả cao. Điều này đặc biệt quan trọng đối với các hoạt chất có sinh khả dụng thấp khi sử dụng ở dạng thông thường.
5.2. Nano hóa giúp ổn định hoạt chất
Một trong những lợi ích quan trọng của công nghệ nano là khả năng ổn định hoạt chất, ngăn chặn quá trình oxy hóa và bảo vệ hoạt chất khỏi tác động của môi trường. Nhờ vậy, cao dược liệu có thể có hạn sử dụng dài hơn mà không bị suy giảm chất lượng.
Bên cạnh đó, công nghệ nano cũng giúp cải thiện độ tan của các hoạt chất trong nước, giúp sản phẩm dễ dàng hòa tan và hấp thu tốt hơn khi sử dụng. Điều này mở ra nhiều tiềm năng ứng dụng cho cao dược liệu trong các sản phẩm thực phẩm chức năng và dược phẩm hiện đại.
6. Xu hướng công nghệ sản xuất cao dược liệu trong tương lai
6.1. Tự Động Hóa Và Trí Tuệ Nhân Tạo (AI) – “Chuyên Gia” Không Biết Mệt Mỏi
Tưởng tượng một dây chuyền sản xuất cao dược liệu hoạt động gần như không cần sự can thiệp của con người – đó chính là tương lai mà AI mang lại. Các thuật toán thông minh sẽ giám sát nhiệt độ, áp suất và thời gian chiết xuất, đảm bảo hoạt chất quý giá không bị thất thoát. Không chỉ vậy, AI còn có thể phân tích dữ liệu sản xuất để phát hiện sai sót trước khi chúng kịp xảy ra. Điều này giúp giảm thiểu lãng phí nguyên liệu, nâng cao độ đồng nhất của cao dược liệu và tối ưu hóa hiệu suất sản xuất.
6.2. Sản Xuất Bền Vững – Cao Dược Liệu “Xanh” Đang Lên Ngôi
Ngành công nghiệp đang chuyển mình mạnh mẽ với xu hướng bảo vệ môi trường. Công nghệ xanh như chiết xuất siêu tới hạn CO2, sử dụng dung môi thân thiện với thiên nhiên và tối ưu hóa quy trình để giảm thiểu chất thải đang dần thay thế phương pháp truyền thống. Hơn nữa, nguồn nguyên liệu đầu vào cũng được kiểm soát chặt chẽ, hướng đến tiêu chuẩn hữu cơ, không hóa chất bảo vệ thực vật và bền vững hơn với hệ sinh thái.
Tương lai của ngành cao dược liệu không chỉ là hiệu quả, mà còn an toàn, thông minh và thân thiện với môi trường.
7. Kết luận
Công nghệ hiện đại đóng vai trò quan trọng trong việc sản xuất cao dược liệu chất lượng cao. Việc ứng dụng các phương pháp chiết xuất tiên tiến, cô đặc, sấy và nano hóa giúp giữ nguyên hoạt chất, nâng cao hiệu quả sử dụng. Trong tương lai, ngành này sẽ tiếp tục phát triển theo hướng bền vững, tự động hóa và cá nhân hóa sản phẩm để đáp ứng nhu cầu ngày càng cao của thị trường.
Xem bài viết liên quan:
Tại Sao Cùng Một Loại Cao Dược Liệu Nhưng Công Dụng Lại Khác Nhau? Hé Lộ Sự Thật Bị Che Giấu!
Ứng Dụng Cao Dược Liệu Trong Sản Phẩm Chăm Sóc Sức Khỏe
Dear all,
The SRE team is pleased to share that since January we have been gradually
migrating the WMF MediaWiki production environment to PHP 8.1! This
upgrade from PHP 7.4 brings performance improvements, security
enhancements, and access to newer language features that will help to
ensure long-term stability and maintainability. You can find more
information in the PHP release announcements[0].
Key points
-
API and Web traffic will be running entirely on PHP 8.1 by the end of
March[1]
-
If you maintain extensions or tools, please ensure they are compatible
with PHP 8.1.
-
If you encounter issues that you believe are triggered by the migration
to PHP 8.1, we encourage you to open a subtask[2].
-
If the issue is urgent and/or widespread, you can escalate directly to
SRE via the #wikimedia-sre channel on IRC.
Thanks to everyone who contributed to this long-running effort to prepare
both MediaWiki and our production environment for this transition. Special
appreciation goes to the developers who reported and resolved any bugs and
production issues along the way—your efforts have been invaluable in moving
forward this migration according to plan.
If you have any questions or concerns, please add your comments on
Phabricator under the relevant tasks[1][3]
Best Regards,
Scott French & Effie Mouzeli
On Behalf of the SRE team
[0] (Release Announcement) https://www.php.net/releases/8.0/en.php and
https://www.php.net/releases/8.1/en.php
[1] (MediaWiki on PHP 8.1 production traffic ramp-up)
https://phabricator.wikimedia.org/T383845
[2] (PHP 8.1 issues found during WMF rollout/ramp up)
https://phabricator.wikimedia.org/T379874
[3] (Migrate WMF production from PHP 7.4 to PHP 8.1)
https://phabricator.wikimedia.org/T319432
Hi everyone,
TL;DR: You might not have to wait very long on CI if your patchset has
already passed its tests in a prior run with the same exact
dependencies and CI configuration.
At our WMF Developer Experience offsite back in December 2024, the
Release Engineering team discussed a few different ways we might
reduce continuous integration wait times for MediaWiki contributors.
One hypothesis was that there was a significant number of cases where
automated testing was repeated against the exact same setup: the same
MediaWiki patchset, the same dependency versions, and the same CI
configuration.
This could happen during retest scenarios, for example, or for
backports to release branches. If correct, we might be able to safely
skip redundant test execution and save developers and deployers some
serious wait time.
So we ran an experiment to prove _or disprove_ our hypothesis. If we
were right, maybe we could skip execution during those scenarios. If
we were wrong, there would be no reason to complicate our CI jobs
further.
We first rolled out a partial "success caching" implementation in
Quibble[1] that computed a SHA256 digest to represent the uniqueness
of the test run and stuck it in a memcached instance at the end of a
successful run.
The digest was computed from:
1. The job name (a good and easy proxy for overall CI setup).
2. The `HEAD^{tree}` of each of the sorted Git repos under test
(core, extensions, skins, etc).
(Note the `HEAD^{tree}` is used over simply `HEAD` because it more
accurately represents the working tree on disk after you checkout a
commit, and the `HEAD` commit is almost never unique due to our gating
system creating temporary merge commits, etc.)
Quibble would then check its cache on subsequent runs for an identical
digest/key, and report to the console if it found a match. We let this
run for a couple of weeks, scraping the Jenkins logs, and then did
some reporting on it.
Our hypothesis was proven to be correct. Redundant test execution was
occuring, and more so for the gate-and-submit pipelines that test
mainline bound changes, and even more often in pipelines testing
changes against release branches (weekly train branches and long-term
release).
You can see my summary on the task for details[2], but the most
striking numbers were:
- 6.4% of test runs in gate-and-submit (merges to mainline branches)
were redundant
- 28.3% of test runs in gate-and-submit-wmf (merges to weekly release
branches) were redundant
- 163 _hours_ of CI wall time could have been saved had we skipped
execution of redundant tests
Naturally, with such encouraging numbers, we went ahead with the final
implementation. Quibble will now exit early and successfully if:
1. The patch under test has not changed from a previously successful run.
2. The extensions/skins/vendor dependencies have not changed.
3. The setup for MediaWiki and its testsuite has not changed
(database type, vendor vs. composer usage, etc).
Hopefully this leads to some pleasant surprises for folks when waiting
on CI, especially during backport deployment windows.
Thanks to everyone in Release Engineering for collaborating on the
idea, and a special thanks to Antoine Musso for thinking through the
details with me and for reviewing my Python code!
Please reply or reach out on IRC (#wikimedia-releng) if you want to
know more about it.
To pleasant surprises!
Cheers,
Dan
[1]: https://www.mediawiki.org/wiki/Continuous_integration/Quibble
[2]: https://phabricator.wikimedia.org/T383243#10584349
--
Dan Duvall
Staff Software Engineer, Release Engineering
Wikimedia Foundation
TL;DR:
The SRE Observability team asks that no new metrics be deployed to
Graphite. *On April 15th, 2025, the service will be configured to a
read-only state*, disabling new metric ingestion—details in T228380 [1].
Please disable or migrate all existing Graphite metrics to Prometheus [2]
and retire the corresponding panels and dashboards as applicable before the
noted date.
Technical Sunsetting of Graphite for Prometheus Reminder
The SRE Observability team has been operating Prometheus [1] in production
for several years, offering several operational benefits over Graphite.
After a long period of observation and usage, the team has determined that
migrating MW off Graphite ensures we stay ahead with a supported, scalable
metrics platform for more effective dimensional metrics analysis and
storage.
Notice and Action Required
The team plans to make Graphite read-only on April 15th 2025 and begin the
formal deprecation of Graphite in production [1].
We ask all teams and maintainers to check this dashboard [3] and related
task T350592 [4] and claim metrics and dashboards in associated tasks or
components under their care. Disable/remove any unused metrics and
dashboards first, then follow the process outlined in the task to migrate
all “in-use” metrics before April 15th. After this date, Graphite will be
read-only, and no new data will be ingested.
Graphite will continue to be available for another year to provide
historical data in read-only “mode” while new history is recorded in
Prometheus. Please see the tracking task T228380 [2] or roadmap [5] for
additional details.
Why We’re Migrating from Graphite to Prometheus
We have been utilizing Prometheus in production for several years as it offers
several benefits over Graphite
<https://prometheus.io/docs/introduction/comparison/>. Migrating MW off
Graphite ensures we stay ahead with a supported, scalable metrics platform
for more effective, multidimensional metrics analysis and storage.
Prometheus provides more robust data labeling, storage, and query
capabilities. This initiative is fundamental in unifying our metrics,
enhancing monitoring, improving MW observability, and reducing tool
fragmentation. We’re moving from Graphite to Prometheus because of critical
limitations in our current setup.
Here’s also what you need to know:
-
Graphite is Dropping Data: Our existing Graphite hosts have recently
been saturated by too much metrics traffic (UDP). The 1G network interfaces
on these hosts are overloaded, causing packets (and, therefore, data) to be
lost. We don’t know precisely how much data is dropped, but it’s enough to
be noticeable. Instead of investing in fixing this old system, we’re
focusing on migrating Prometheus, which is more reliable. The hardware
that powers the current system will also reach its end-of-life and be
retired by Q4 of the end of FY 2025/2026 (June 2026).
-
Prometheus Works Differently: Different internal methods for data
processing, sampling, and calculation between Graphite and Prometheus mean
that numbers on both sides won't necessarily align or match 100%; this is
expected. More information available
-
More Accurate Metrics: Prometheus handles timing metrics and counters
differently from Graphite. You may see higher counts for certain metrics,
such as timing metrics—this is expected and can be explained
further in statsite:
architecture
<https://github.com/statsite/statsite?tab=readme-ov-file#architecture>
if you’d like the specifics.
-
Compare Patterns, Not Values: If you’re comparing numbers between
Graphite and Prometheus, focus on the pattern and trends rather than exact
values. Differences in how the two systems process data mean that exact
numbers won’t always match. However, the overall trend should be the same.
Frequently Asked Questions
-
Will you be migrating historical data from Graphite to Prometheus?
We do not plan to migrate data from graphite to Prometheus, and while it is
technically feasible, we don't have enough documented requests. Instead, we
will run both systems in parallel for a while (1yr) to allow new historical
data to cross over before read-only.
-
What if I need data longer than 1 year?
We can also provide graphite files for projects interested in longer
retention and work on possible backfilling alternatives for specific
cases. Details
are in T349521 <https://phabricator.wikimedia.org/T349521>.
-
What if I needed access to graphite for longer?
We can provide a subset of the data in a VM, with a graphite service (in
read-only) available for a discretionary period longer than the year after
the hardware is sunset with limited support as we are sunsetting the
technology. This workaround will be offered until the current graphite and
os deployments are supported.
Related Links:
[1] Tech debt: sunsetting of Graphite
https://phabricator.wikimedia.org/T228380
[2] Wikitech:Prometheus https://wikitech.wikimedia.org/wiki/Prometheus
[3] List of dashboards w/Graphite queries
https://grafana.wikimedia.org/d/K6DEOo5Ik/grafana-graphite-datasource-utili…
[4] EPIC: Migrate in-use metrics and dashboards to statslib
https://phabricator.wikimedia.org/T350592
[5] Graphite Deprecation Roadmap
https://wikitech.wikimedia.org/wiki/Graphite/Deprecation_Roadmap
Thank you for reading! Be safe and happy.
Best,
Leo
*Leo Mata* (he/him)
Engineering Manager - Observability
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello everyone,
The Spring 2025 MediaWiki Users & Developers Conference will be held about
two months from now, on May 14-16 (with an optional half-day workshop on
May 13), at the NASA offices in Sandusky, Ohio, USA:
https://meza.wiki/mwplus/MediaWiki_Users_and_Developers_Spring_2025_Confere…
Everyone is encouraged to attend, to meet and discuss MediaWiki-related
topics relating to both the Wikimedia world and uses within companies,
organizations, etc.
As the program chair, I would like to specifically encourage you all to
consider giving a talk, on any topic related to MediaWiki usage or
development. Talks can be given remotely, although priority will be given
to in-person attendees if there's an overflow. To propose a talk for this
conference, just fill out this form:
https://meza.wiki/mwplus/Form:Proposed_talk
Thank you, and I hope to see you in Sandusky!
-Yaron