Ĉi-septembre, Broadcom (antaŭe CA) publikigis la novan version 20.2 de sia solvo DX Operations Intelligence (DX OI). Sur la merkato, ĉi tiu produkto estas poziciigita kiel tegmenta monitora sistemo. La sistemo kapablas ricevi kaj kombini datumojn de monitoraj sistemoj de diversaj domajnoj (reto, infrastrukturo, aplikoj, datumbazoj) de kaj CA kaj de triaj produktantoj, inkluzive de malfermfontaj solvoj (Zabbix, Prometheus kaj aliaj).

La ĉeffunkcio de DX OI estas la kreado de plentaŭga rimed-serva modelo (RSM) bazita sur konfiguraciobjektoj (CUoj) kiuj plenigas la stokregistran datumbazon kiam integrite kun triapartaj sistemoj. DX OI efektivigas funkciojn de Maŝina Lernado kaj Artefarita Inteligenteco (ML kaj AI) super la datumoj enirantaj la platformon, kio ebligas al vi taksi / antaŭdiri la probablecon de fiasko de specifa CI kaj la gradon de efiko de fiasko sur komerca servo bazita sur specifa CI. Krome, DX OI estas ununura punkto de kolekto de monitoraj eventoj kaj, sekve, integriĝo kun la Service Desk-sistemo, kio estas nediskutebla avantaĝo de uzado de la sistemo en unuigitaj monitoraj centroj per devoŝanĝoj de organizoj. En ĉi tiu artikolo, ni rakontos al vi pli pri la funkcieco de la sistemo kaj montros la uzant- kaj administrantajn interfacojn.

DX OI Solva Arkitekturo

La DX-platformo havas mikroservan arkitekturon, instalitan kaj funkciantan Kubernetes aŭ OpenShift. La sekva figuro montras la komponantojn de la solvo, kiuj povas esti uzataj kiel sendependaj monitoraj iloj aŭ anstataŭigitaj per ekzistantaj monitoraj sistemoj kun similaj funkcioj (estas ekzemploj de tiaj sistemoj en la figuro) kaj poste konektitaj al la pluvombrelo DX OI. En la diagramo malsupre:

• Monitorado de moveblaj aplikoj en DX App Experience Analytics;
• Monitorado de agado de aplikaĵo en DX APM;
• Infrastrukturmonitorado en DX Infrastructure Manager;
• Monitorado de retaj aparatoj en DX NetOps Manager.

DX-komponentoj funkcias per Kubernetes-areto kaj skalo simple lanĉante novajn PODojn. Malsupre estas supranivela solvdiagramo.

Administrado, skalo kaj ĝisdatigo de la DX-platformo estas farita en la administra konzolo. De unuopa konzolo, vi povas administri plur-luantan arkitekturon kiu povas etendi plurajn entreprenojn aŭ plurajn komercajn unuojn ene de firmao. En ĉi tiu modelo, ĉiu instalaĵo povas esti agordita individue kiel luanto kun sia propra aro de agordoj.

La Administra Konzolo estas TTT-bazita operacio kaj sistema administrado kiu provizas administrantojn per konsekvenca, unuigita interfaco por plenumi monitorajn grapoladministrajn taskojn.

Novaj luantoj por komercaj unuoj aŭ entreprenoj ene de la firmao estas deplojitaj en minutoj. Ĉi tio estas avantaĝo, se vi volas havi unuigitan monitoran sistemon, sed samtempe, je la platforma nivelo (kaj ne alirrajtoj), limigi monitorajn objektojn inter fakoj.

Rimedo-servaj modeloj kaj monitorado de komercaj servoj

DX OI havas enkonstruitajn mekanismojn por krei servojn kaj disvolvi klasikan PCM kun la tasko de la logiko de influo kaj pezoj inter servokomponentoj. Ekzistas ankaŭ mekanismoj por eksporti PCM de ekstera CMDB. La suba figuro montras la enkonstruitan PCM-redaktilon (atentu la ligajn pezojn).

DX OI disponigas holisman vidon de ŝlosilaj agado-indikiloj por komercaj aŭ IT-servoj sur granula nivelo, inkluzive de servodisponeblo kaj fiaska riska prognozo. La ilo ankaŭ povas doni sciojn pri la efiko de rendimenta problemo aŭ ŝanĝo en la strukturo de IT-komponentoj (aplikaĵo aŭ infrastrukturo) sur komerca servo. La suba figuro estas interaga panelo, kiu montras la staton de ĉiuj servoj.

Ni rigardu pli detale la servon de Cifereca Bankado kiel ekzemplon. Alklakante la nomon de la servo, ni iras al la detala PCM-servo. Ni vidas, ke la statuso de la servo de Cifereca Bankado dependas de la stato de infrastrukturo kaj transakciaj subservoj kun malsamaj pezoj. Labori kun pezoj kaj montri ilin estas interesa avantaĝo de DX OI.

Topologio estas grava elemento de funkcia monitorado de la entrepreno, permesante al funkciigistoj kaj inĝenieroj analizi la rilaton inter komponentoj, trovi la radikan kaŭzon kaj influon.

DX OI Topology Viewer estas servo kiu uzas topologiajn datumojn de domajnaj monitoraj sistemoj, kiuj kolektas datumojn rekte de monitoraj objektoj. La ilo estas dizajnita por serĉi plurajn topologiajn stokajn tavolojn kaj montri kuntekst-specifan rilatmapon. Por esplori problemojn, vi povas iri al la problema Backend Banking subservo kaj vidi la topologion kaj problemajn komponantojn. Alarmaj mesaĝoj kaj agado-metrikoj ankaŭ povas esti analizitaj por ĉiu komponento.

Analizante la transakciajn komponentojn de Pagoj (uzanttransakcioj), ni povas spuri komercajn KPI-valorojn, kiuj ankaŭ estas konsiderataj kiam oni kalkulas la haveblecstatuson kaj sanon de la servo. Ekzemplo de komerca KPI estas montrita malsupre:

Analizo de eventoj (Analitiko de alarmoj)

Algoritma brua redukto per kraŝa amasiĝo

Unu el la ĉefaj trajtoj de DX OI en okazaĵtraktado estas clustering. La mekanismo funkcias sur ĉiuj alarmoj venantaj en la sistemon por identigi ŝablonojn bazitajn sur malsamaj kuntekstoj kaj kombini ilin en grupojn. Ĉi tiuj aretoj estas memlernantaj kaj ne bezonas esti mane agorditaj.

Tiel, clustering permesas al uzantoj kombini kaj grupigi grandegan nombron da eventoj kaj analizi nur tiujn, kiuj havas komunan kuntekston. Ekzemple, aro de eventoj kiuj reprezentas okazaĵon kiu influas aplikojn aŭ datumcentron. La situacioj estas kreitaj uzante maŝinlern-bazitajn grupigajn algoritmojn kiuj uzas tempan korelacion, topologian rilaton kaj gepatran lingvopretigon por analizo. La malsupraj figuroj montras ekzemplojn de bildigo de amasigitaj grupoj de mesaĝoj, la tielnomitaj Situaciaj Alarmoj kaj Evidence Timeline, kiuj montras la ĉefajn grupajn parametrojn kaj la procezon de reduktado de la nombro da bruaj eventoj.

Radika problemo-analizo kaj kraŝa korelacio

En la hodiaŭa hibrida medio, uzanttransakcio povas influi plurajn sistemojn, kiuj estas uzataj dinamike. Kiel rezulto, pluraj atentigoj povas esti generitaj de malsamaj sistemoj, sed rilataj al la sama problemo aŭ okazaĵo. DX OI uzas proprietajn mekanismojn por subpremi superfluajn kaj duplikatajn alarmojn kaj korelacii rilatajn atentigojn por plibonigita detekto de kritikaj problemoj kaj pli rapida rezolucio.

Ni konsideru ekzemplon kiam la sistemo ricevas multajn krizmesaĝojn por malsamaj objektoj (KE) kiuj subestas unu servon. En kazo de efiko al la havebleco kaj operableco de la servo, la sistemo generos servo-alarmo (Serva Alarmo), indikos kaj nomumos la verŝajnan radikan kaŭzon (problemo CI kaj alarmmesaĝo sur la CI) kiu kontribuis al la malkresko de rendimento aŭ fiasko de la servo. La suba figuro montras la kraŝan bildigon por Webex-servo.

DX OI permesas vin labori kun eventoj per intuiciaj agoj en la interreta interfaco de la sistemo. Uzantoj povas permane asigni eventojn al la respondeca dungito por solvi problemojn, restarigi/akcepti atentigojn, krei biletojn aŭ sendi retpoŝtajn sciigojn, ruli aŭtomatigitajn skriptojn por solvi krizon (Remediation Workflow, pli pri tio poste). Tiamaniere, DX OI permesas al ŝanĝfunkciigistoj temigi la radikan alarmmesaĝon kaj ankaŭ helpi simpligi la procezon de ordigo de mesaĝoj en amasigitajn tabelojn.

Maŝinaj algoritmoj por prilaborado de metrikoj kaj analizi rendimentajn datumojn

Maŝina lernado permesas vin spuri, kunigi kaj bildigi ŝlosilajn rendimentajn indikilojn por iu ajn tempodaŭro, kio donas al la uzanto la sekvajn avantaĝojn:

• Detekto de proplempunktoj kaj rendimento anomalioj;
• Komparo de pluraj indikiloj por la samaj aparatoj, interfacoj aŭ retoj;
• Komparo de la samaj indikiloj ĉe pluraj objektoj;
• Komparo de diversaj indikiloj por unu kaj pluraj objektoj;
• Komparo de plurdimensia metriko por pluraj objektoj.

Por analizi la metrikojn enirantajn la sistemon, DX OI uzas la funkciojn de maŝinanalitiko uzante matematikajn algoritmojn, kiuj helpas redukti la tempon kiam fiksas statikajn sojlojn kaj generas avertojn kiam anomalioj okazas.

La rezulto de aplikado de matematikaj algoritmoj estas la konstruado de la tielnomitaj probablaj distribuoj de la metrika valoro (Malofta, Verŝajna, Centro, Meznomo, Aktua). La figuroj supre kaj malsupre montras la probablajn distribuojn.

La du leteroj supre montras la sekvajn datumojn:

• Faktaj datumoj (Faktaj). Faktaj datumoj estas grafikaj kiel solida nigra linio (sen alarmoj) aŭ kolora solida linio (alarmkondiĉo). La linio estas kalkulita surbaze de la realaj datumoj por la metriko. Komparante la realajn datumojn kaj la medianon, vi povas rapide vidi la variadon en la metriko. Kiam okazaĵo okazas, la nigra linio ŝanĝiĝas al kolora solida linio, kiu respondas al la severeco de la okazaĵo kaj montras ikonojn kun la responda severeco super la grafikaĵo. Ekzemple, ruĝa por kritika anomalio, oranĝa por grava anomalio, kaj flava por negrava anomalio.
• Averaĝa valoro de la indikilo (Averaĝa valoro). La mediano aŭ meznombro por mezuro estas montrita kiel griza linio en la diagramo. La averaĝa valoro montriĝas kiam ne estas sufiĉe da historiaj datumoj.
• La meza valoro de la indikilo (Centra valoro). La meza linio estas la mezo de la intervalo kaj estas montrita kiel verda punktlinio. La zonoj plej proksimaj al ĉi tiu linio estas plej proksimaj al la tipaj valoroj de la indikilo.
• Komunaj datumoj (Komuna Valoro). La Totala Zono-datumoj spuras la plej proksiman al la centra linio aŭ normalo por via metriko kaj estas montrata kiel malhelverda stango. Analizaj kalkuloj metas la totalan zonon unu percentilo super aŭ sub normalo.
• probabilismaj datumoj. La probablaj zonaj datumoj estas montritaj sur la grafikaĵo kun verda stango. La sistemo metas la probablozonon du procentojn super aŭ sub normalo.
• Maloftaj datumoj. Maloftaj zonaj datumoj estas montritaj sur la grafikaĵo kiel helverda stango. La sistemo metas zonon kun maloftaj metrikaj valoroj tri procentoj super aŭ sub la normo kaj signalas la konduton de la indikilo ekster la normala gamo, dum la sistemo generas la tiel nomatan Anomalia Atentigo.

Anomalio estas mezurado aŭ okazaĵo kiu estas malkonsekvenca kun la normala agado de metriko. Detekto de anomalioj por identigi problemojn kaj kompreni tendencojn en infrastrukturo kaj aplikoj estas ŝlosila trajto de DX OI. Detekto de anomalioj ebligas al vi kaj rekoni nekutiman konduton (ekzemple, servilo kiu respondas pli malrapide ol kutime, aŭ nekutiman retan agadon kaŭzitan de hako) kaj respondi laŭe (komencante okazaĵon, rulante aŭtomatan Solvigan skripton).

La funkcio de detekto de anomalioj de DX OI disponigas la sekvajn avantaĝojn:

• Vi ne bezonas agordi sojlojn. DX OI sendepende komparos la datumojn kaj identigos anomaliojn.
• DX OI inkluzivas pli ol dek algoritmojn de artefarita inteligenteco kaj maŝinlernado, inkluzive de EWMA (Exponentially-Weighted-Moving-Average) kaj KDE (Kernel Density Estimation). Ĉi tiuj algoritmoj permesas al vi fari rapidan analizon pri radika kaŭzo kaj antaŭdiri estontajn metrikojn.

Prognoza analizo kaj fiaskaj alarmoj

Predictive Insights estas trajto kiu uzas la potencon de maŝinlernado por identigi ŝablonojn kaj tendencojn. Surbaze de ĉi tiuj tendencoj, la sistemo antaŭdiras eventojn, kiuj povas okazi en la estonteco. Ĉi tiuj mesaĝoj indikas, ke ago devas esti prenita antaŭ ol la metrikaj valoroj preterpasas la normalan gamon, influante kritikajn komercajn servojn. Prognozaj komprenoj estas montritaj en la figuro malsupre.

Kaj ĉi tio estas bildigo de prognozaj atentigoj por specifa metriko.

Antaŭvidante la ŝarĝon de komputika potenco kun la funkcio starigi ŝarĝoscenarojn

La funkcio de kapacita planado de Kapacito Analytics helpas administri IT-resursojn certigante, ke rimedoj estas taŭge grandecoj por plenumi nunajn kaj estontajn komercajn bezonojn. Vi povos optimumigi la agadon kaj efikecon de ekzistantaj rimedoj, plani kaj pravigi ajnan financan investon.

La funkcio de Kapacita Analizo en DX OI provizas la jenajn avantaĝojn:

• Antaŭvidado de kapabloj dum pintaj sezonoj;
• Determino de la momento, kiam necesas pliaj rimedoj por certigi la kvaliton de la servo;
• Aĉeti pliajn rimedojn nur kiam necesas;
• Efika infrastrukturo kaj retadministrado;
• Forigi nenecesajn energikostojn identigante subuzitajn resursojn;
• Faru rimedan ŝarĝan takson en kazo de planita pliiĝo de postulo por servo aŭ rimedo.

La paĝo de Capacity Analytics DX OI (montrita malsupre) havas la jenajn fenestraĵojn:

• Rimeda Kapacito-Statuso;
• Kontrolitaj grupoj / servoj (Monitoritaj Grupoj / Servoj);
• Grandaj konsumantoj de rimedoj (Top Capacity Consumers).

La ĉefa paĝo de Kapacita Analizo montras rimedkomponentojn, kiuj estas tro uzataj kaj elĉerpitaj. Ĉi tiu paĝo helpas al administrantoj de platformo trovi trouzitajn rimedojn kaj helpas ilin regrandigi kaj optimumigi rimedojn. La stato de resursoj povas esti analizita surbaze de kolorkodoj kaj iliaj respektivaj valoroj. Rimedoj estas klasifikitaj laŭ sia grado de ŝtopiĝo sur la rimeda kapacita statuspaĝo. Vi povas alklaki ĉiun el la koloroj por vidi liston de la komponantoj en la elektita kategorio. Poste, varmomapo estas montrata kun ĉiuj objektoj kaj prognozoj por 12 monatoj, kio permesas vin identigi rimedojn, kiuj estas elĉerpitaj.

Por ĉiu el la metrikoj en Kapacita Analizo, vi povas specifi la filtrilojn, kiujn DX Operational Intelligence uzas por fari prognozojn (figuro malsupre).

La sekvaj filtriloj estas disponeblaj:

• Metrika. La metriko uzota por la prognozo.
• Bazu sur. Elekto de la kvanto de historiaj datumoj, kiuj estos uzataj por konstrui prognozojn por la estonteco. Ĉi tiu kampo estas uzata por kompari kaj analizi lastmonatajn tendencojn, lastajn 3-monatajn tendencojn, ĉiujarajn tendencojn ktp.
• Kresko. La atendata kreskorapideco de la laborkvanto, kiun vi volas uzi por modeligi la kapacitan prognozon. Ĉi tiuj datumoj povas esti uzataj por antaŭvidi kreskon preter antaŭvidoj. Ekzemple, uzado de rimedoj estas atendita plialtiĝi je 40 procentoj pro la malfermo de nova oficejo.

Loga analizo

La analizo de protokolo de DX OI provizas:

• kolekto, agregado de ŝtipoj de malsamaj fontoj (inkluzive de tiuj akiritaj per agentejo kaj senagentaj metodoj);
• analizado kaj datumnormaligo;
• analizo por plenumo de la fiksitaj kondiĉoj kaj generacio de eventoj;
• korelacio de eventoj bazitaj sur protokoloj, inkluzive de eventoj ricevitaj kiel rezulto de monitorado de IT-infrastrukturo;
• datuma bildigo bazita sur analizo en DX Dashboards;
• konkludoj pri la havebleco de servoj bazitaj sur la analizo de datumoj de la protokoloj.

Kolekto de protokoloj uzantaj senagentan metodon estas farita de la sistemo por Vindozaj Eventaj protokoloj kaj Syslog. Agent-bazita maniero kolekti tekstajn protokolojn.

Aŭtomatigita Kriza Solvo-Funkcio (Sanigo)

Aŭtomatigitaj agoj por korekti la krizon (Remediation Workflow) permesas vin solvi problemojn, kiuj kaŭzis la generacion de evento en DX OI. Ekzemple, se CPU-uzoproblemo generas alarmon, la Remediation Workflow solvas la problemon rekomencante la servilon kiu havas la problemon. La integriĝo inter DX OI kaj la aŭtomatigsistemo permesas solvajn procezojn esti ekigitaj de la eventa konzolo en DX Operational Intelligence kaj spuritaj en la aŭtomatigsistemkonzolo.

Post integriĝo kun aŭtomatiga sistemo, vi povas ekigi aŭtomatajn agojn por korekti ajnan krizon en la DX OI-konzolo el la kunteksto de alarmo. Vi povas vidi rekomenditajn agojn kune kun informoj pri konfidaj procentoj (la verŝajneco, ke la situacio estos solvita per la ago).

Komence, kiam ne ekzistas statistikoj pri la rezultoj de la Remediation Workflow, la rekomenda motoro sugestas kandidatojn bazitajn sur ŝlosilvortaj serĉoj, tiam la maŝinlernado-rezultoj estas uzataj, kaj la motoro komencas rekomendi heŭristik-bazitan kuracan teknikon. Tuj kiam vi komencos taksi la rezultojn de la ricevitaj sugestoj, la precizeco de la rekomendoj pliboniĝos.

Ekzemplo de uzantreagoj: la uzanto elektas ĉu ili ŝatas aŭ malŝatas la proponitan agon, kaj la sistemo konsideras ĉi tiun elekton kiam faras pliajn rekomendojn. Ŝati/malŝatas:

La rekomenditaj korektaj agoj por speciala alarmo baziĝas sur kombinaĵo de religoj, kiu determinas ĉu la ago estas akceptebla. DX OI venas kun preta uzebla integriĝo kun Aŭtomata Aŭtomatigo.

Integriĝo de DX OI kun triapartaj sistemoj

Ni ne traktos la integriĝon de datumoj de denaskaj Broadcom-monitoraj produktoj (DX NetOps, DX Infrastructure Management, DX Application Performance Management). Anstataŭe, ni rigardu kiel datumoj de triaj partiaj sistemoj estas integritaj kaj konsideru ekzemplon de integriĝo kun unu el la plej popularaj sistemoj - Zabbix.

Por integriĝo kun triapartaj sistemoj, la DX Gateway-komponento estas uzata. DX Gateway konsistas el 3 komponentoj - On-Prem Gateway, RESTmon kaj Log Collector (Logstash). Vi povas instali ĉiujn 3 komponantojn aŭ nur tiun, kiun vi bezonas, ŝanĝante la ĝeneralan agordan dosieron kiam vi instalas DX Gateway. La figuro malsupre montras la arkitekturon DX Gateway.

Ni konsideru la celon de la DX Gateway-komponentoj aparte.

En-Prem Enirejo. Ĉi tio estas interfaco, kiu kolektas alarmojn de la DX-platformo kaj sendas alarmajn eventojn al triaj sistemoj. La On-Prem Gateway funkcias kiel balotisto, kiu periode kolektas eventodatenojn de la DX OI uzante la HTTPS-peton API, tiam sendas atentigojn al triapartnera servilo kiu estas integrita kun la DX-platformo uzante rethokojn.

DX Log Collector ricevas syslog de retaj aparatoj aŭ serviloj kaj alŝutas ilin al OI. DX Log Collector permesas apartigi la programaron kiu generas la mesaĝojn, la sistemon kiu stokas ilin, kaj la programaro kiu raportas kaj analizas ilin. Ĉiu mesaĝo estas etikedita kun objektokodo indikanta la specon de softvaro generanta la mesaĝon, kaj severecnivelo estas asignita al ĝi. En DX Dashboards, ĉio ĉi tiam povas esti vidita.

DX RESTmon integras kun triaj produktoj/servoj per REST API kaj pasas datumojn al OI. La malsupra figuro montras la funkciadon de DX RESTmon uzante la ekzemplon de integriĝo kun Solarwinds kaj SCOM-monitorsistemoj.

Ĉefaj trajtoj de DX RESTmon:

• Konektiĝu al iu ajn tria datumfonto por ricevi datumojn:
  • PULL: konekti kaj preni datumojn de publikaj REST-APIoj;
  • PUSH: datumfluo al RESTmon per REST.
• Subteno por JSON kaj XML-formatoj;
• Ricevu metrikojn, atentigojn, grupojn, topologion, inventaron kaj protokolojn;
• Pretaj konektiloj por diversaj iloj/teknologioj, ankaŭ eblas evoluigi konektilon al iu ajn fonto kun malfermita API (listo de boksitaj konektiloj en la suba figuro);
• Subteno por baza aŭtentikigo (defaŭlte) kiam vi aliras la Swagger-interfacon kaj API;
• HTTPS-subteno (defaŭlte) por ĉiuj enirantaj kaj elirantaj mesaĝoj;
• Subteno por envenantaj kaj elirantaj prokuriloj;
• Potencaj teksto-analizaj kapabloj por protokoloj ricevitaj per REST;
• Agordigebla analizado kun RESTmon por efika analizado kaj bildigo de protokoloj;
• Subteno por ĉerpi informojn pri grupoj de aparatoj de monitorado de aplikaĵoj kaj elŝutado al OI por analizo kaj bildigo;
• Subteno por regula esprimo kongruo. Ĉi tio povas esti uzata por analizi kaj kongrui protokolmesaĝojn ricevitajn per REST, kaj por generi aŭ fermi eventojn surbaze de certaj regula esprimo kondiĉoj.

Nun ni rigardu la procezon de agordo de DX OI-integriĝo kun Zabbix per DX RESTmon. Boksita integriĝo prenas la sekvajn datumojn de Zabbix:

• stokregistraj datumoj;
• topologio;
• Problemoj;
• metrikoj.

Ĉar la konektilo por Zabbix estas havebla el la skatolo, ĉio, kio devas esti farita por agordi la integriĝon, estas ĝisdatigi la profilon kun la IP-adreso kaj konto de la API de la servilo Zabbix, kaj poste alŝuti la profilon per la retejo Swagger. . Ekzemplo estas en la sekvaj du figuroj.

Post agordo de la integriĝo, la DX OI-analizaj funkcioj priskribitaj supre estos disponeblaj por datumoj venantaj de Zabbix, nome: Alarm Analytics, Performance Analytics, Predictive Insights, Service Analytics and Remediation. La figuro malsupre montras ekzemplon de analizado de agado-metriko por objektoj integritaj de Zabbix.

konkludo

DX OI estas pintnivela analiza ilo, kiu provizos signifan operacian efikecon al IT-sekcioj, permesante al vi fari pli rapide kaj pli ĝustajn decidojn por plibonigi la kvaliton de IT-servoj kaj komercaj servoj per transdomajna konteksta analizo. Por aplikaĵposedantoj kaj komercaj unuoj, DX OI kalkulos haveblecon kaj servokvaliton ne nur en la kunteksto de IT-teknologiaj metrikoj, sed ankaŭ komercaj KPI-oj derivitaj de finuzantaj transakciaj statistikoj.

Se vi ŝatus lerni pli pri ĉi tiu solvo, bonvolu peti demo aŭ piloto en maniero oportuna por vi en nia retejo.

fonto: www.habr.com