Zabbix ni mfumo wa ufuatiliaji. Kama mfumo mwingine wowote, inakabiliwa na matatizo makuu matatu ya mifumo yote ya ufuatiliaji: kukusanya na kuchakata data, kuhifadhi historia, na kuisafisha.
Hatua za kupokea, kuchakata na kurekodi data huchukua muda. Sio sana, lakini kwa mfumo mkubwa hii inaweza kusababisha ucheleweshaji mkubwa. Tatizo la uhifadhi ni suala la ufikiaji wa data. Zinatumika kwa ripoti, hundi na vichochezi. Kuchelewa katika ufikiaji wa data pia huathiri utendaji. Wakati hifadhidata inakua, data isiyo na maana lazima ifutwe. Kuondoa ni operesheni ngumu ambayo pia hula rasilimali kadhaa.
Matatizo ya ucheleweshaji wakati wa kukusanya na kuhifadhi katika Zabbix hutatuliwa kwa caching: aina kadhaa za cache, caching katika database. Ili kutatua tatizo la tatu, caching haifai, kwa hiyo Zabbix alitumia TimescaleDB. Atakuambia juu yake Andrey Gushchin - mhandisi wa msaada wa kiufundi . Andrey amekuwa akisaidia Zabbix kwa zaidi ya miaka 6 na ana uzoefu wa moja kwa moja na utendaji.
TimescaleDB inafanyaje kazi, inaweza kutoa utendaji gani ikilinganishwa na PostgreSQL ya kawaida? Zabbix ina jukumu gani kwa hifadhidata ya TimescaleDB? Jinsi ya kuanza kutoka mwanzo na jinsi ya kuhama kutoka PostgreSQL na ni usanidi gani una utendaji bora? Kuhusu haya yote chini ya kukata.
Changamoto za Uzalishaji
Kila mfumo wa ufuatiliaji unakabiliwa na changamoto mahususi za utendaji. Nitazungumza juu ya tatu kati yao: ukusanyaji na usindikaji wa data, uhifadhi, na kusafisha historia.
Ukusanyaji na usindikaji wa data haraka. Mfumo mzuri wa ufuatiliaji unapaswa kupokea data zote kwa haraka na kuzichakata kulingana na vichochezi - kulingana na vigezo vyake. Baada ya usindikaji, mfumo lazima pia uhifadhi haraka data hii kwenye hifadhidata kwa matumizi ya baadaye.
Hifadhi ya historia. Mfumo mzuri wa ufuatiliaji unapaswa kuhifadhi historia katika hifadhidata na kutoa ufikiaji rahisi wa vipimo. Historia inahitajika ili kutumika katika ripoti, grafu, vichochezi, vizingiti, na vipengee vya data vilivyokokotwa.
Inafuta historia. Wakati mwingine inakuja siku ambayo hauitaji kuhifadhi vipimo. Kwa nini unahitaji data iliyokusanywa miaka 5 iliyopita, mwezi mmoja au miwili: baadhi ya nodi zimefutwa, seva pangishi au vipimo hazihitajiki tena kwa sababu zimepitwa na wakati na hazikusanywi tena. Mfumo mzuri wa ufuatiliaji unapaswa kuhifadhi data za kihistoria na kuzifuta mara kwa mara ili hifadhidata isikua.
Kusafisha data ya zamani ni suala muhimu ambalo linaathiri sana utendaji wa hifadhidata.
Inahifadhi kwenye Zabbix
Katika Zabbix, simu za kwanza na za pili zinatatuliwa kwa kutumia caching. RAM hutumika kukusanya na kuchakata data. Kwa hifadhi - historia katika vichochezi, grafu na vipengele vya data vilivyokokotwa. Kwa upande wa hifadhidata kuna kache kwa chaguzi za kimsingi, kwa mfano, grafu.
Kuhifadhi kando ya seva ya Zabbix yenyewe ni:
- ConfigurationCache;
- ValueCache;
- HistoriaCache;
- TrendsCache.
Fikiria kwa kina zaidi.
ConfigurationCache
Hii ndiyo akiba kuu tunapohifadhi vipimo, seva pangishi, vipengee vya data, vichochezi - kila kitu tunachohitaji kwa Uchakataji Mapema na kwa ukusanyaji wa data.
Haya yote yamehifadhiwa katika ConfigurationCache ili kutounda maswali yasiyo ya lazima kwenye hifadhidata. Baada ya seva kuanza, tunasasisha kashe hii, kuunda na kusasisha mara kwa mara usanidi.
Mkusanyiko wa data
Mchoro ni mkubwa kabisa, lakini jambo kuu ndani yake ni wakusanyaji. Hizi ni "wapiga kura" anuwai - michakato ya kusanyiko. Wanawajibika kwa aina tofauti za mkusanyiko: wanakusanya data kupitia SNMP, IPMI, na kuhamisha zote kwa PreProcessing.
Watoza wameainishwa kwa rangi ya machungwa.
Zabbix imekokotoa vipengee vya kujumlisha ambavyo vinahitajika ili kujumlisha ukaguzi. Ikiwa tunazo, tunaziletea data moja kwa moja kutoka kwa ValueCache.
Inachakata Akiba ya Historia
Wakusanyaji wote hutumia ConfigurationCache kupokea kazi. Kisha wanazihamisha kwa PreProcessing.
PreProcessing hutumia ConfigurationCache kupokea hatua za PreProcessing. Inachakata data hii kwa njia mbalimbali.
Baada ya kuchakata data kwa kutumia PreProcessing, tunaihifadhi kwenye HistoryCache kwa kuchakatwa. Hii inahitimisha ukusanyaji wa data na tunaendelea na mchakato mkuu katika Zabbix - Kisawazishaji cha historia, kwa kuwa ni usanifu wa monolithic.
Kumbuka: PreProcessing ni operesheni ngumu sana. Kwa v 4.2 imehamishwa hadi kwa seva mbadala. Ikiwa una Zabbix kubwa sana na idadi kubwa ya vipengele vya data na mzunguko wa mkusanyiko, basi hii inafanya kazi iwe rahisi zaidi.
Akiba ya ValueCache, historia na mitindo
Usawazishaji wa historia ni mchakato mkuu ambao huchakata kiotomatiki kila kipengele cha data, yaani, kila thamani.
Usawazishaji wa historia huchukua thamani kutoka kwaHistoryCache na hukagua Usanidi kwa uwepo wa vichochezi vya hesabu. Ikiwa zipo, inahesabu.
Kisawazishaji cha historia huunda tukio, kupanda ili kuunda arifa ikihitajika na usanidi, na rekodi. Ikiwa kuna vichochezi vya usindikaji unaofuata, basi huhifadhi thamani hii katika ValueCache ili usipate jedwali la historia. Hivi ndivyo ValueCache inavyojazwa na data ambayo ni muhimu kukokotoa vichochezi na vipengele vilivyokokotwa.
Kisawazishaji cha historia huandika data zote kwenye hifadhidata, na huandika kwa diski. Mchakato wa kuchakata unaishia hapa.
Kuhifadhi kwenye hifadhidata
Kwa upande wa hifadhidata kuna kache mbalimbali unapotaka kutazama grafu au ripoti juu ya matukio:
Innodb_buffer_poolkwa upande wa MySQL;shared_bufferskwa upande wa PostgreSQL;effective_cache_sizekwa upande wa Oracle;shared_poolkwa upande wa DB2.
Kuna kache zingine nyingi, lakini hizi ndio kuu kwa hifadhidata zote. Wanakuruhusu kuhifadhi data kwenye RAM ambayo inahitajika mara nyingi kwa maswali. Wana teknolojia zao wenyewe kwa hili.
Utendaji wa hifadhidata ni muhimu
Seva ya Zabbix hukusanya data kila mara na kuiandika. Inapowashwa tena, pia inasoma kutoka kwa historia ili kujaza ValueCache. Hutumia maandishi na ripoti Zabbix API, ambayo imejengwa kwenye kiolesura cha Wavuti. Zabbix API hufikia hifadhidata na kupata data muhimu ya grafu, ripoti, orodha za matukio na matoleo mapya zaidi.
Kwa taswira - grafana. Hii ni suluhisho maarufu kati ya watumiaji wetu. Inaweza kutuma maombi moja kwa moja kupitia API ya Zabbix na kwa hifadhidata, na kuunda shindano fulani la kupokea data. Kwa hivyo, urekebishaji bora na bora wa hifadhidata unahitajika ili kuendana na uwasilishaji wa haraka wa matokeo na majaribio.
Housekeeper
Changamoto ya tatu ya utendaji katika Zabbix ni kusafisha historia kwa kutumia Mlinzi wa Nyumba. Inafuata mipangilio yote - vipengele vya data vinaonyesha muda gani wa kuhifadhi mienendo ya mabadiliko (mwenendo) kwa siku.
Tunahesabu TrendsCache kwa kuruka. Data inapofika, tunaijumlisha kwa saa moja na kuirekodi katika majedwali kwa mienendo ya mabadiliko ya mitindo.
Mlinzi wa nyumba huanza na kufuta habari kutoka kwa hifadhidata kwa kutumia "teua" za kawaida. Hii haifai kila wakati, kama inavyoweza kuonekana kutoka kwa grafu za utendaji wa michakato ya ndani.
Grafu nyekundu inaonyesha kuwa Kisawazishaji cha Historia kina shughuli nyingi kila wakati. Grafu ya chungwa iliyo juu ni Mlinzi wa Nyumba, ambayo inaendeshwa kila mara. Anasubiri hifadhidata kufuta safu zote alizotaja.
Je, unapaswa kulemaza Mlinzi wa Nyumba wakati gani? Kwa mfano, kuna "Kitambulisho cha Kipengee" na unahitaji kufuta safu mlalo elfu 5 za mwisho ndani ya muda fulani. Bila shaka, hii hutokea kwa index. Lakini kawaida hifadhidata ni kubwa sana, na hifadhidata bado inasoma kutoka kwa diski na kuiweka kwenye kashe. Hii daima ni operesheni ya gharama kubwa sana kwa hifadhidata na, kulingana na saizi ya hifadhidata, inaweza kusababisha shida za utendaji.
Mlinzi wa nyumba ni rahisi kuzima. Katika kiolesura cha Wavuti kuna mpangilio katika "Jumla ya Utawala" kwa Mlinzi wa Nyumba. Tunazima Utunzaji Nyumbani kwa historia ya mitindo ya ndani na haidhibiti tena.
Msaidizi wa nyumba alizimwa, grafu zimesawazishwa - ni shida gani zinaweza kuwa katika kesi hii na ni nini kinachoweza kusaidia kutatua changamoto ya tatu ya utendaji?
Kugawanya - kugawanya au kugawa
Kawaida, kizigeu kimeundwa kwa njia tofauti kwenye kila hifadhidata ya uhusiano ambayo nimeorodhesha. Kila mmoja ana teknolojia yake mwenyewe, lakini ni sawa kwa ujumla. Kuunda kizigeu kipya mara nyingi husababisha shida fulani.
Kawaida, kizigeu husanidiwa kulingana na "usanidi" - idadi ya data ambayo huundwa kwa siku moja. Kama sheria, Ugawaji hutolewa kwa siku moja, hii ndio kiwango cha chini. Kwa mwenendo wa kundi jipya - mwezi 1.
Thamani zinaweza kubadilika ikiwa "mipangilio" ni kubwa sana. Ikiwa "usanidi" mdogo ni hadi 5 nvps (thamani mpya kwa sekunde), ya kati ni kutoka 000 hadi 5, basi kubwa ni zaidi ya 000 nvps. Hizi ni mitambo mikubwa na mikubwa sana inayohitaji usanidi makini wa hifadhidata.
Kwenye usakinishaji mkubwa sana, kipindi cha siku moja kinaweza kisiwe sawa. Nimeona sehemu za MySQL za GB 40 au zaidi kwa siku. Hii ni kiasi kikubwa sana cha data ambacho kinaweza kusababisha matatizo na inahitaji kupunguzwa.
Partitioning inatoa nini?
Majedwali ya kugawa. Mara nyingi hizi ni faili tofauti kwenye diski. Mpango wa hoja huchagua kizigeu kimoja kwa njia bora zaidi. Kawaida ugawaji hutumiwa na anuwai - hii pia ni kweli kwa Zabbix. Tunatumia "muhuri wa wakati" hapo - wakati tangu mwanzo wa enzi. Hizi ni nambari za kawaida kwetu. Unaweka mwanzo na mwisho wa siku - hii ni kizigeu.
Uondoaji wa haraka - DELETE. Faili/jedwali dogo limechaguliwa, badala ya uteuzi wa safu mlalo za kufutwa.
Inaharakisha sana urejeshaji wa data SELECT - hutumia sehemu moja au zaidi, badala ya meza nzima. Ikiwa unapata data ambayo ina umri wa siku mbili, inarejeshwa kutoka kwa hifadhidata haraka kwa sababu unahitaji tu kupakia faili moja kwenye kashe na kuirudisha, sio jedwali kubwa.
Mara nyingi hifadhidata nyingi pia huharakishwa INSERT - kuingizwa kwenye meza ya mtoto.
TimescaleDB
Kwa v 4.2, tulielekeza mawazo yetu kwa TimescaleDB. Hiki ni kiendelezi cha PostgreSQL kilicho na kiolesura asili. Kiendelezi hufanya kazi kwa ufanisi na data ya mfululizo wa saa, bila kupoteza manufaa ya hifadhidata za uhusiano. TimescaleDB pia hugawanyika kiotomatiki.
TimescaleDB ina dhana yenye shinikizo la damu (hypertable) unayounda. Ina vipande - partitions. Chunks hudhibitiwa kiotomatiki vipande vya shinikizo la damu ambavyo haviathiri vipande vingine. Kila sehemu ina safu yake ya wakati.
TimescaleDB dhidi ya PostgreSQL
TimescaleDB inafanya kazi kwa ufanisi. Watengenezaji wa kiendelezi wanadai kuwa wanatumia algoriti sahihi zaidi ya kuchakata hoja, haswa inserts . Kadiri saizi ya seti ya data inavyoongezeka, kanuni hudumisha utendaji wa kila mara.
Baada ya safu mlalo milioni 200, PostgreSQL kwa kawaida huanza kudorora sana na kupoteza utendakazi hadi 0. TimescaleDB hukuruhusu kuingiza "vipengee" kwa kiwango chochote cha data kwa ufanisi.
Ufungaji
Kufunga TimescaleDB ni rahisi kwa kifurushi chochote. KATIKA kila kitu kinaelezewa kwa undani - inategemea vifurushi rasmi vya PostgreSQL. TimescaleDB pia inaweza kujengwa na kukusanywa kwa mikono.
Kwa hifadhidata ya Zabbix tunawasha kiendelezi tu:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Unawasha extension na uunde kwa hifadhidata ya Zabbix. Hatua ya mwisho ni kuunda hypertable.
Inahamisha majedwali ya historia hadi TimescaleDB
Kuna kazi maalum kwa hili create_hypertable:
SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1
Kazi ina vigezo vitatu. Kwanza - jedwali katika hifadhidata, ambayo unahitaji kuunda hypertable. Pili - shamba, kulingana na ambayo unahitaji kuunda chunk_time_interval - muda wa vipande vya kizigeu vya kutumika. Katika kesi yangu, muda ni siku moja - 86.
Kigezo cha tatu - migrate_data. Ukiweka true, kisha data zote za sasa huhamishiwa kwenye vipande vilivyoundwa awali. Niliitumia mwenyewe migrate_data. Nilikuwa na takriban TB 1, ambayo ilichukua zaidi ya saa moja. Hata katika baadhi ya matukio, wakati wa kupima, nilifuta data ya kihistoria ya aina za wahusika ambazo hazikuhitajika kuhifadhi, ili nisiwahamisha.
Hatua ya mwisho - UPDATE: katika db_extension weka timescaledbili hifadhidata ielewe kuwa kiendelezi hiki kipo. Zabbix huiwasha na kutumia sintaksia na maswali kwa hifadhidata kwa usahihi - vipengele hivyo ambavyo ni muhimu kwa TimescaleDB.
Usanidi wa vifaa
Nilitumia seva mbili. Kwanza - Mashine ya VMware. Ni ndogo kabisa: vichakata 20 vya Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz, GB 16 za RAM na SSD ya GB 200.
Nilisakinisha PostgreSQL 10.8 juu yake na Debian 10.8-1.pgdg90+1 OS na mfumo wa faili wa xfs. Nilisanidi kila kitu kidogo ili kutumia hifadhidata hii, ukiondoa kile Zabbix yenyewe itatumia.
Kwenye mashine hiyo hiyo kulikuwa na seva ya Zabbix, PostgreSQL na mawakala wa mzigo. Nilikuwa na mawakala 50 waliokuwa wakitumia LoadableModulekwa haraka sana kutoa matokeo tofauti: nambari, kamba. Nilijaza hifadhidata na data nyingi.
Awali usanidi uliomo Vipengele 5 data kwa mwenyeji. Takriban kila kipengele kilikuwa na kichochezi cha kuifanya iwe sawa na usakinishaji halisi. Katika baadhi ya matukio kulikuwa na trigger zaidi ya moja. Kwa nodi moja ya mtandao kulikuwa Vichochezi 3-000.
Muda wa Usasishaji wa Kipengee cha Data - Sekunde 4-7. Nilidhibiti mzigo yenyewe kwa kutumia sio tu mawakala 50, lakini kuongeza zaidi. Pia, kwa kutumia vipengele vya data, nilirekebisha mzigo kwa nguvu na kupunguza muda wa sasisho hadi 4 s.
PostgreSQL. 35 nvps
Uendeshaji wangu wa kwanza kwenye vifaa hivi ulikuwa kwenye PostgreSQL safi - maadili elfu 35 kwa sekunde. Kama unaweza kuona, kuingiza data huchukua sehemu za sekunde - kila kitu ni nzuri na haraka. Jambo pekee ni kwamba diski ya 200 GB SSD inajaza haraka.
Hii ni dashibodi ya kawaida ya utendaji ya seva ya Zabbix.
Grafu ya kwanza ya bluu ni nambari ya maadili kwa sekunde. Grafu ya pili upande wa kulia ni upakiaji wa michakato ya ujenzi. Ya tatu ni kupakia michakato ya uundaji wa ndani: visawazishaji vya historia na Mlinzi wa Nyumba, ambayo imekuwa ikifanya kazi hapa kwa muda mrefu.
Grafu ya nne inaonyesha matumizi ya HistoryCache. Hii ni aina ya bafa kabla ya kuingiza kwenye hifadhidata. Grafu ya tano ya kijani kibichi inaonyesha matumizi ya ValueCache, ambayo ni, ni vichochezi vingapi vya ValueCache - hii ni maadili elfu kadhaa kwa sekunde.
PostgreSQL. 50 nvps
Kisha nikaongeza mzigo hadi maadili elfu 50 kwa sekunde kwenye vifaa sawa.
Wakati wa kupakia kutoka kwa Mlinzi wa Nyumba, kuingiza maadili elfu 10 kulichukua sekunde 2-3.
Mlinzi wa nyumba tayari anaanza kuingilia kazi.
Grafu ya tatu inaonyesha kuwa, kwa ujumla, mzigo wa watekaji na wasanifu wa historia bado uko 60%. Katika grafu ya nne, HistoryCache tayari inaanza kujaza kikamilifu wakati wa operesheni ya Mlinzi wa Nyumba. Imejaa 20%, ambayo ni karibu 0,5 GB.
PostgreSQL. 80 nvps
Kisha nikaongeza mzigo hadi maadili elfu 80 kwa sekunde. Hii ni takriban vitu elfu 400 vya data na vichochezi elfu 280.
Gharama ya upakiaji ya visawazishaji thelathini vya historia tayari iko juu kabisa.
Pia niliongeza vigezo mbalimbali: visawazishaji vya historia, kache.
Kwenye maunzi yangu, upakiaji wa visawazishaji vya historia uliongezeka hadi kiwango cha juu. HistoriaCache ilijazwa kwa haraka na data - data ya kuchakatwa ilikuwa imekusanywa kwenye bafa.
Wakati huu wote niliona jinsi processor, RAM na vigezo vingine vya mfumo vilitumiwa, na nikagundua kuwa utumiaji wa diski ulikuwa katika kiwango cha juu.
Nimepata matumizi uwezo wa juu wa diski kwenye vifaa hivi na kwenye mashine hii pepe. Kwa nguvu kama hiyo, PostgreSQL ilianza kusambaza data kikamilifu, na diski haikuwa na wakati wa kuandika na kusoma.
Seva ya pili
Nilichukua seva nyingine, ambayo tayari ilikuwa na wasindikaji 48 na 128 GB ya RAM. Niliirekebisha - niliiweka kwa usawazishaji wa historia 60, na nikapata utendakazi unaokubalika.
Kwa kweli, hii tayari ni kikomo cha tija ambapo kitu kinahitajika kufanywa.
TimescaleDB. 80 nvps
Kazi yangu kuu ni kujaribu uwezo wa TimescaleDB dhidi ya mzigo wa Zabbix. Thamani elfu 80 kwa sekunde ni nyingi, frequency ya kukusanya metriki (isipokuwa kwa Yandex, kwa kweli) na "usanidi" mkubwa.
Kuna mteremko katika kila grafu - huu ndio uhamishaji wa data. Baada ya kushindwa katika seva ya Zabbix, wasifu wa upakiaji wa syncer wa historia ulibadilika sana - ilishuka mara tatu.
TimescaleDB hukuruhusu kuingiza data karibu mara 3 kwa kasi zaidi na kutumia HistoryCache kidogo.
Ipasavyo, utapokea data kwa wakati unaofaa.
TimescaleDB. 120 nvps
Kisha nikaongeza idadi ya vipengele vya data hadi elfu 500. Kazi kuu ilikuwa kupima uwezo wa TimescaleDB - nilipokea thamani iliyohesabiwa ya maadili 125 kwa pili.
Hii ni "kuanzisha" inayofanya kazi ambayo inaweza kufanya kazi kwa muda mrefu. Lakini kwa kuwa diski yangu ilikuwa TB 1,5 tu, niliijaza katika siku chache.
Jambo muhimu zaidi ni kwamba wakati huo huo sehemu mpya za TimescaleDB ziliundwa.
Hii haionekani kabisa kwa utendaji. Wakati partitions zinaundwa katika MySQL, kwa mfano, kila kitu ni tofauti. Kwa kawaida hii hutokea usiku kwa sababu inazuia uingizaji wa jumla, kufanya kazi na meza na inaweza kuunda uharibifu wa huduma. Hii sivyo ilivyo kwa TimescaleDB.
Kwa mfano, nitaonyesha grafu moja kutoka kwa wengi katika jamii. Katika picha, TimescaleDB imewezeshwa, shukrani ambayo mzigo wa kutumia io.weight kwenye processor umeshuka. Matumizi ya vipengele vya mchakato wa ndani pia yalipungua. Kwa kuongezea, hii ni mashine ya kawaida kwenye diski za pancake za kawaida, sio SSD.
Matokeo
TimescaleDB ni suluhisho nzuri kwa "kuanzisha" ndogo., ambayo huathiri utendaji wa diski. Itakuruhusu kuendelea kufanya kazi vizuri hadi hifadhidata ihamishwe kwa maunzi haraka iwezekanavyo.
TimescaleDB ni rahisi kusanidi, inatoa faida ya utendaji, inafanya kazi vizuri na Zabbix na ina faida zaidi ya PostgreSQL.
Ikiwa unatumia PostgreSQL na huna mpango wa kuibadilisha, ninapendekeza tumia PostgreSQL na kiendelezi cha TimescaleDB kwa kushirikiana na Zabbix. Suluhisho hili linafanya kazi kwa ufanisi hadi "kuanzisha" kati.
Tunaposema "utendaji wa hali ya juu" tunamaanisha . Hutachukua muda mrefu kusubiri ili kujifunza kuhusu teknolojia na mbinu zinazowezesha huduma kuhudumia mamilioni ya watumiaji. Orodha kwa Novemba 7 na 8 tayari tumekusanya, lakini hapa zaidi inaweza kupendekezwa.
Jiandikishe kwa yetu и , ambamo tunafichua vipengele vya mkutano ujao, na kujua jinsi ya kunufaika zaidi nayo.
Chanzo: mapenzi.com