首页 文章 精选 留言 我的

精选列表

搜索[企微管家],共10000篇文章
优秀的个人博客,低调大师

鸿蒙轻内核M核的故障管家:Fault异常处理

摘要:本文先简单介绍下Fault异常类型,向量表及其代码,异常处理C语言程序,然后详细分析下异常处理汇编函数实现代码。 本文分享自华为云社区《鸿蒙轻内核M核源码分析系列十八 Fault异常处理》,作者:zhushy。 Fault异常处理模块与OpenHarmony LiteOS-M内核芯片架构相关,提供对HardFault、MemManage、BusFault、UsageFault等各种故障异常处理。有关Cortex-M芯片相关的知识不在本文讨论,请自行参考《Cortex™-M7 Devices Generic User Guide》等官方资料。本文先简单介绍下Fault异常类型,向量表及其代码,异常处理C语言程序,然后详细分析下异常处理汇编函数实现代码。文中所涉及的源码,以OpenHarmony LiteOS-M内核为例,均可以在开源站点https://gitee.com/openharmony/kernel_liteos_m获取。 1、Fault Type异常类型 如下图中的Fault类型表格所示,Fault表示各种故障,Handler表示故障处理机制,Bit Name标记故障的寄存器的Bit位,Fault status register故障状态寄存器。该图摘自《Cortex™-M7 Devices Generic User Guide》。 2、Vector table向量表 向量表包含栈指针的复位值和开始地址,也叫异常向量。异常可以看作特殊的中断,异常编号Exception number, 中断请求号IRQ number,偏移值offset,向量Vector的对应关系如下图所示,本文主要关注NMI、HardFault、Memory management fault、Bus fault、Usage fault、SVCall等异常。 在中断初始化时,会初始化该异常向量表,代码位置kernel\arch\arm\cortex-m7\gcc\los_interrupt.c。⑴处的HalExcNMI,⑵处的HalExcHardFault,⑶处的HalExcMemFault,⑷处的HalExcBusFault,⑸处的HalExcUsageFault,⑹处的HalExcSvcCall这些中断异常处理函数定义在kernel\arch\arm\cortex-m7\gcc\los_exc.S。本文我们主要分析这些汇编函数的代码。 ⑺处开始的这两行代码也比较重要,通过更改系统处理控制与状态寄存器(System Handler Control and State Register)的bit位来使能相应的异常,通过更改配置与控制寄存器(Configuration and Control Register)的bit位来使能除零异常。 LITE_OS_SEC_TEXT_INIT VOID HalHwiInit(VOID) { #if (LOSCFG_USE_SYSTEM_DEFINED_INTERRUPT == 1) UINT32 index; g_hwiForm[0] = 0; /* [0] Top of Stack */ g_hwiForm[1] = Reset_Handler; /* [1] reset */ for (index = 2; index < OS_VECTOR_CNT; index++) { /* 2: The starting position of the interrupt */ g_hwiForm[index] = (HWI_PROC_FUNC)HalHwiDefaultHandler; } /* Exception handler register */ ⑴ g_hwiForm[NonMaskableInt_IRQn + OS_SYS_VECTOR_CNT] = HalExcNMI; ⑵ g_hwiForm[HARDFAULT_IRQN + OS_SYS_VECTOR_CNT] = HalExcHardFault; ⑶ g_hwiForm[MemoryManagement_IRQn + OS_SYS_VECTOR_CNT] = HalExcMemFault; ⑷ g_hwiForm[BusFault_IRQn + OS_SYS_VECTOR_CNT] = HalExcBusFault; ⑸ g_hwiForm[UsageFault_IRQn + OS_SYS_VECTOR_CNT] = HalExcUsageFault; ⑹ g_hwiForm[SVCall_IRQn + OS_SYS_VECTOR_CNT] = HalExcSvcCall; g_hwiForm[PendSV_IRQn + OS_SYS_VECTOR_CNT] = HalPendSV; g_hwiForm[SysTick_IRQn + OS_SYS_VECTOR_CNT] = SysTick_Handler; /* Interrupt vector table location */ SCB->VTOR = (UINT32)(UINTPTR)g_hwiForm; #endif #if (__CORTEX_M >= 0x03U) /* only for Cortex-M3 and above */ NVIC_SetPriorityGrouping(OS_NVIC_AIRCR_PRIGROUP); #endif /* Enable USGFAULT, BUSFAULT, MEMFAULT */ ⑺ *(volatile UINT32 *)OS_NVIC_SHCSR |= (USGFAULT | BUSFAULT | MEMFAULT); /* Enable DIV 0 and unaligned exception */ *(volatile UINT32 *)OS_NVIC_CCR |= DIV0FAULT; return; } 3、HalExcHandleEntry异常处理C程序入口 HalExcHandleEntry异常处理函数是汇编异常函数跳转到C语言程序的入口,定义在文件kernel\arch\arm\cortex-m7\gcc\los_interrupt.c,被kernel\arch\arm\cortex-m7\gcc\los_exc.S文件中的汇编函数调用。函数参数由汇编程序中的R0-R3寄存器传值进来,汇编程序中的寄存器和HalExcHandleEntry函数参数对应关系如下表所示: 下面我们分析下函数的源代码,⑴处的标签表示异常类型参数的高16位用于特色的标记,主要用于标记故障地址是否有效、是否故障发生在中断中,是否支持浮点等。⑵处增加中断计数和嵌套异常数目。⑶记录异常类型,⑷处如果记录了有效的故障地址,则获取故障地址。⑸处如果当前运行任务存在时,若标记了异常发生在中断,则记录中断号,并记录异常发生在中断内,否则记录任务编号,并记录异常发生在任务内。如果当前运行任务为空,则异常发生在初始化阶段。⑹处如果异常类型里包含支持浮点数的标记,则相应处理下。⑺处输出异常信息到控制台。 LITE_OS_SEC_TEXT_INIT VOID HalExcHandleEntry(UINT32 excType, UINT32 faultAddr, UINT32 pid, EXC_CONTEXT_S *excBufAddr) { ⑴ UINT16 tmpFlag = (excType >> 16) & OS_NULL_SHORT; /* 16: Get Exception Type */ ⑵ g_intCount++; g_excInfo.nestCnt++; ⑶ g_excInfo.type = excType & OS_NULL_SHORT; ⑷ if (tmpFlag & OS_EXC_FLAG_FAULTADDR_VALID) { g_excInfo.faultAddr = faultAddr; } else { g_excInfo.faultAddr = OS_EXC_IMPRECISE_ACCESS_ADDR; } ⑸ if (g_losTask.runTask != NULL) { if (tmpFlag & OS_EXC_FLAG_IN_HWI) { g_excInfo.phase = OS_EXC_IN_HWI; g_excInfo.thrdPid = pid; } else { g_excInfo.phase = OS_EXC_IN_TASK; g_excInfo.thrdPid = g_losTask.runTask->taskID; } } else { g_excInfo.phase = OS_EXC_IN_INIT; g_excInfo.thrdPid = OS_NULL_INT; } ⑹ if (excType & OS_EXC_FLAG_NO_FLOAT) { g_excInfo.context = (EXC_CONTEXT_S *)((CHAR *)excBufAddr - LOS_OFF_SET_OF(EXC_CONTEXT_S, uwR4)); } else { g_excInfo.context = excBufAddr; } ⑺ OsDoExcHook(EXC_INTERRUPT); OsExcInfoDisplay(&g_excInfo); HalSysExit(); } 4、Los_Exc异常处理汇编函数 上文介绍Vector table向量表时,已经提到了在文件kernel\arch\arm\cortex-m7\gcc\los_exc.S中定义的的异常处理函数,如下。当发生Fault故障异常时,会调度执行这些异常处理函数,本节会详细分析函数的源代码来掌握内核如何处理这些发生的异常。这6个函数处理过程类似,我们选择2个典型的函数进行分析。 .global HalExcNMI .global HalExcHardFault .global HalExcMemFault .global HalExcBusFault .global HalExcUsageFault .global HalExcSvcCall 4.1 HalExcNMI 当发生NMI(Non Maskable Interrupt,不可屏蔽中断)时,会触发运行HalExcNMI汇编函数,该函数的执行流程如下图。下文会结合该流程图来阅读函数代码。 HalExcNMI函数代码如下,⑴处给R0寄存器赋值OS_EXC_CAUSE_NMI,该值等于16,对应文件kernel\arch\arm\cortex-m7\gcc\los_arch_interrupt.h中的异常类型宏定义OS_EXC_CAUSE_NMI,均为16。该值对应HalExcHandleEntry函数的第一个参数。⑵处设置故障地址,该值对应HalExcHandleEntry函数的第二个参数。⑶处跳转到函数osExcDispatch继续执行。 .type HalExcNMI, %function .global HalExcNMI HalExcNMI: .fnstart .cantunwind ⑴ MOV R0, #OS_EXC_CAUSE_NMI ⑵ MOV R1, #0 ⑶ B osExcDispatch .fnend 下面分析的一些函数比较通用,其他异常处理函数也都会调用。 4.1.1 osExcDispatch函数 osExcDispatch函数代码如下,⑴处加载Interrupt Active Bit Registers中断活跃位寄存器基地址。中断活跃位寄存器共有8个,NVIC_IABR0-NVIC_IABR7,每个寄存器包含32位,可以对应32个中断号,共支持256个中断。其中,IABR[0]的 bit位0~31 分别对应中断号0~31;IABR[1]的bit位0~31对应中断32~63;其他以此类推。⑵处设置循环计数,对应8个寄存器,后文会循环遍历8个寄存器查询是否存在活跃的中断。 .type osExcDispatch, %function .global osExcDispatch osExcDispatch: .fnstart .cantunwind ⑴ LDR R2, =OS_NVIC_ACT_BASE ⑵ MOV R12, #8 // R12 is hwi check loop counter .fnend 4.1.2 _hwiActiveCheck函数 执行完上述osExcDispatch函数代码后,会继续执行随后的函数_hwiActiveCheck的代码。⑴处读取活跃位寄存器的数值,然后执行⑵比较寄存器数值与0的大小,如果相等,说明该活跃位寄存器对应的中断均不活跃,然后跳转到_hwiActiveCheckNext。如果不等于0,则执行⑶,参数类型的高16位标记为中断。⑷处代码根据中断活跃位计算中断号,并赋值给寄存器R2,该值对应HalExcHandleEntry函数的第三个参数。具体计算方式为,首先反转活跃中断位寄存器数值R3,并保存到R2,然后计算高位0的数量。把计数值R12加1,然后左移5位(等于乘以32),然后加上R2,就是中断号。 .type _hwiActiveCheck, %function .global _hwiActiveCheck _hwiActiveCheck: .fnstart .cantunwind ⑴ LDR R3, [R2] // R3 store active hwi register when exc ⑵ CMP R3, #0 BEQ _hwiActiveCheckNext // exc occurred in IRQ ⑶ ORR R0, R0, #FLAG_HWI_ACTIVE ⑷ RBIT R2, R3 CLZ R2, R2 AND R12, R12, #1 ADD R2, R2, R12, LSL #5 // calculate R2 (hwi number) as pid .fnend 4.1.3 _ExcInMSP函数和_NoFloatInMsp函数 如果有活跃的中断,则继续执行后续的代码。处理中断时,使用的主栈处理函数_ExcInMSP。⑴处比较异常返回值和#0XFFFFFFED的大小,如果相等说明支持浮点计算则继续执行后续代码,如果不相等则不支持浮点计算,会跳转到函数_NoFloatInMsp函数。有关异常返回值的更多信息请参考《Cortex™-M7 Devices Generic User Guide》表格Table 2-15 Exception return behavior。 如果支持浮点计算时,执行⑵把栈指针加上104赋值给R3寄存器,然后压栈,该值对应HalExcHandleEntry函数的第四个参数。104的大小应该来源于结构体EXC_CONTEXT_S。⑶处把寄存器PRIMASK数值复制到R12寄存器,然后把R4-R12寄存器压栈。⑷处把浮点寄存器压栈,⑸处跳转到函数_handleEntry。 当不支持浮点计算时,执行函数_NoFloatInMsp。⑹处把栈指针加上32赋值给R3寄存器,然后压栈,该值对应HalExcHandleEntry函数的第四个参数。然后把R3压栈,把寄存器PRIMASK数值复制到R12,然后压栈R4-R12。和支持浮点时的差别就是,不需要压栈D8-D15寄存器。⑺处把参数类型高位上加上不支持浮点的标记,然后跳转到函数_handleEntry。 .type _ExcInMSP, %function .global _ExcInMSP _ExcInMSP: .fnstart .cantunwind ⑴ CMP LR, #0XFFFFFFED BNE _NoFloatInMsp ⑵ ADD R3, R13, #104 PUSH {R3} ⑶ MRS R12, PRIMASK // store message-->exc: disable int? PUSH {R4-R12} // store message-->exc: {R4-R12} #if ((defined(__FPU_PRESENT) && (__FPU_PRESENT == 1U)) && \ (defined(__FPU_USED) && (__FPU_USED == 1U))) ⑷ VPUSH {D8-D15} #endif ⑸ B _handleEntry .fnend .type _NoFloatInMsp, %function .global _NoFloatInMsp _NoFloatInMsp: .fnstart .cantunwind ⑹ ADD R3, R13, #32 PUSH {R3} // save IRQ SP // store message-->exc: MSP(R13) MRS R12, PRIMASK // store message-->exc: disable int? PUSH {R4-R12} // store message-->exc: {R4-R12} ⑺ ORR R0, R0, #FLAG_NO_FLOAT B _handleEntry .fnend 4.1.4 _hwiActiveCheckNext函数 遍历中断活跃位寄存器时,如果前一个寄存器没有活跃的中断则执行函数_hwiActiveCheckNext判断下一个寄存器是否有活跃的中断。⑴处把活跃位寄存器地址偏移4字节,计数减1,如果还有其他活跃位寄存器,则跳转到函数_hwiActiveCheck继续判断。否则执行后续的代码,⑵处加载System Handler Control and State Register(缩写SHCSRS)系统处理控制与状态寄存器的地址,然后加载半字节数值。⑶处加载掩码0xC00,该数值二进制的第10、第11位为1。SHCSRS寄存器的第11位对应SysTick异常活跃位,第10位对应PendSV异常活跃位。⑷处R2、R3进行逻辑与计算,然后把结果与0进行比较,如果结果为0,说明没有发生ysTick异常或PendSV异常。如果结果为1,说明发生了异常,需要执行⑸跳转到函数_ExcInMSP继续执行,上文已分析该函数。⑹处获取全局变量g_taskScheduled的地址,然后获取其数值,与1进行比较。如果等于1,说明系统已经开始任务调度,会继续执行后续的代码。如果不为1,系统未调度,处于初始化阶段,需要跳转到函数_ExcInMSP继续执行。 如果系统开始了任务调度,此时使用进程栈PSP,执行⑺,判断系统是否支持浮点计算。如果支持则继续执行,否则跳转到函数_NoFloatInPsp。⑻处开始的代码和函数_NoFloatInPsp可以对比着阅读,前者需要压栈浮点寄存器,后者不需要。⑻处把栈指针复制到R2寄存器,然后把栈指针减去96。⑼处把PSP线程栈指针值赋值给R3寄存器,然后把R3加104赋值给寄存器R12,计算出来的值是任务栈指针,然后进行压栈。 ⑽处复制PRIMASK寄存器数值到R12,然后把寄存器R4-R12压栈,接着压栈浮点寄存器D8-D15。⑾处从PSP栈指针开始把R4-R11、D8-D15出栈,然后从R13栈指针开始把D8-D15、R4-R11进行压栈。⑿处跳转到函数_handleEntry继续指向。 .type _hwiActiveCheckNext, %function .global _hwiActiveCheckNext _hwiActiveCheckNext: .fnstart .cantunwind ⑴ ADD R2, R2, #4 // next NVIC ACT ADDR SUBS R12, R12, #1 BNE _hwiActiveCheck /*NMI interrupt exception*/ ⑵ LDR R2, =OS_NVIC_SHCSRS LDRH R2,[R2] ⑶ LDR R3,=OS_NVIC_SHCSR_MASK ⑷ AND R2, R2,R3 CMP R2,#0 ⑸ BNE _ExcInMSP // exc occured in Task or Init or exc // reserved for register info from task stack ⑹ LDR R2, =g_taskScheduled LDR R2, [R2] TST R2, #1 // OS_FLG_BGD_ACTIVE BEQ _ExcInMSP // if exc occurred in Init then branch ⑺ CMP LR, #0xFFFFFFED //auto push floating registers BNE _NoFloatInPsp // exc occurred in Task ⑻ MOV R2, R13 SUB R13, #96 // add 8 Bytes reg(for STMFD) ⑼ MRS R3, PSP ADD R12, R3, #104 PUSH {R12} // save task SP ⑽ MRS R12, PRIMASK PUSH {R4-R12} VPUSH {D8-D15} // copy auto saved task register ⑾ LDMFD R3!, {R4-R11} // R4-R11 store PSP reg(auto push when exc in task) VLDMIA R3!, {D8-D15} VSTMDB R2!, {D8-D15} STMFD R2!, {R4-R11} ⑿ B _handleEntry .fnend .type _NoFloatInPsp, %function .global _NoFloatInPsp _NoFloatInPsp: .fnstart .cantunwind MOV R2, R13 // no auto push floating registers SUB R13, #32 // add 8 Bytes reg(for STMFD) MRS R3, PSP ADD R12, R3, #32 PUSH {R12} // save task SP MRS R12, PRIMASK PUSH {R4-R12} LDMFD R3, {R4-R11} // R4-R11 store PSP reg(auto push when exc in task) STMFD R2!, {R4-R11} ORR R0, R0, #FLAG_NO_FLOAT .fnend 4.1.5 _handleEntry函数 继续分析函数_handleEntry。代码很简单,⑴把栈指针复制给R3,该值对应HalExcHandleEntry函数的第四个参数。⑵处关闭中断,关闭Fault异常,然后执行⑵跳转到C语言的函数HalExcHandleEntry。 _handleEntry: .fnstart .cantunwind ⑴ MOV R3, R13 // R13:the 4th param ⑵ CPSID I CPSID F B HalExcHandleEntry NOP .fnend 4.2 HalExcUsageFault 当发生使用异常UsageFault时,会触发运行HalExcUsageFault汇编函数,该函数的执行流程如下图。下文会结合该流程图来阅读函数代码。 HalExcUsageFault函数代码如下,⑴处把可配置故障状态寄存器Configurable Fault Status Register(CFSR)的地址复制到R0寄存器,然后读取寄存器值到R0寄存器。⑵处把0x030F赋值给R1寄存器,然后左移16位。UsageFault Status Register使用故障状态寄存器的有效性如下,即0-3,8-9为有效位,0x030F的二进制对应这些有效位。⑶处进行逻辑与,这样就计算出实际的使用故障对应的bit位。⑷处把R12赋值为0,然后会继续执行后续的汇编代码osExcCommonBMU。 .type HalExcUsageFault, %function .global HalExcUsageFault HalExcUsageFault: .fnstart .cantunwind ⑴ LDR R0, =OS_NVIC_FSR LDR R0, [R0] ⑵ MOVW R1, #0x030F LSL R1, R1, #16 ⑶ AND R0, R0, R1 ⑷ MOV R12, #0 .fnend 4.2.1 g_uwExcTbl数组 在看osExcCommonBMU函数的代码之前需要了解下g_uwExcTbl数组,g_uwExcTbl数组定义在文件kernel\arch\arm\cortex-m7\gcc\los_interrupt.c,代码如下。 该数组包含32个元素,每个元素对应CFSR寄存器的一个bit位,元素数值在LiteOS-M中定义为异常类型。比如OS_EXC_UF_DIVBYZERO等于异常类型10,为除零异常。 UINT8 g_uwExcTbl[FAULT_STATUS_REG_BIT] = { 0, 0, 0, 0, 0, 0, OS_EXC_UF_DIVBYZERO, OS_EXC_UF_UNALIGNED, 0, 0, 0, 0, OS_EXC_UF_NOCP, OS_EXC_UF_INVPC, OS_EXC_UF_INVSTATE, OS_EXC_UF_UNDEFINSTR, 0, 0, 0, OS_EXC_BF_STKERR, OS_EXC_BF_UNSTKERR, OS_EXC_BF_IMPRECISERR, OS_EXC_BF_PRECISERR, OS_EXC_BF_IBUSERR, 0, 0, 0, OS_EXC_MF_MSTKERR, OS_EXC_MF_MUNSTKERR, 0, OS_EXC_MF_DACCVIOL, OS_EXC_MF_IACCVIOL }; 4.2.2 osExcCommonBMU函数 现在来分析下汇编代码osExcCommonBMU。⑴处计算出R0数值的高位0的个数,加载数组全局变量g_uwExcTbl地址到R3寄存器,然后执行⑵计算是第几个数组元素,加载元素值到R0寄存器。⑶处R0与R12进行逻辑或运算,没有什么影响。R0对应HalExcHandleEntry函数的第一个参数。后续会继续执行osExcDispatch函数,前文已经分析过。 .type osExcCommonBMU, %function .global osExcCommonBMU osExcCommonBMU: .fnstart .cantunwind ⑴ CLZ R0, R0 LDR R3, =g_uwExcTbl ⑵ ADD R3, R3, R0 LDRB R0, [R3] ⑶ ORR R0, R0, R12 .fnend 小结 本文介绍了Fault异常类型,向量表及其代码,异常处理C语言程序,异常处理汇编函数实现代码。感谢阅读,如有任何问题、建议,都可以博客下留言给我,谢谢。 参考资料 Cortex™-M7 Devices Generic User Guide Download 点击关注,第一时间了解华为云新鲜技术~

优秀的个人博客,低调大师

渝企研发物联网平台系统“章鱼”

看过电影《终结者》吗?知道里面的“天网”吗?它可能真的诞生了!不过,是为人类服务。2015年12月8日,重庆云力网通科技有限公司开发出国内乃至全球首个物联网平台系统——“章鱼”,该系统能让链接网络的各个物件无障碍沟通,并让物联网具备“大脑”一样的思考判断能力。 据介绍,这个名叫“章鱼”的物联网平台系统,实际上是一套针对机器开发包的操作系统管理内核,这有点类似于电脑的操作系统,能让各应用软件无障碍沟通、配合、运行。“章鱼”通常被安装在无线路由器内,能让联通网络的各个物件,如门窗、电视、空调等,通过“泛在网络编号管理”(可理解为:一种物件网络沟通语言)实现无障碍沟通,然后将各种信息,在无线路由器内的“章鱼”里进行思考判断得出结论。 比如说,一个运用物联网的智能家居,可以通过联接物件与人沟通解决:家里门窗关没关,是否需要打开空调,空调温度设定为多少摄氏度等问题。而如果在这个智能家居中,安装“章鱼”系统,这个智能家居将拥有自信思考的“大脑”,当接到打开空调的远程指令后,物联网将自行检测门窗是否关闭,从而来判断是否适合打开空调,打开空调后,又会根据室内外温度情况,来选择一个比较适宜的温度。 开发“章鱼”系统的李世平曾参与中国第一台手机的研发,以及中国移动网络的建设。目前任重庆云力网通科技有限公司董事长他向记者表示,不仅仅是判断是否打开空调这样的问题,“章鱼”还能判断家里是否失火?是告诉在家的邻居?还是拨打火警电话?等复杂问题。而且,“章鱼”还能通过后续开发,持续升级,获得更多的思考能力和判断能力,成长为物联网的超级“大脑”。 特别值得一提的是,目前,国内乃至全球的物联网行业还没有一个类似于“章鱼”的平台系统,这是因为各个网络运营商,以及相关物联网公司之间,没有形成一个套可沟通、共享的体系,而“章鱼”采用的“泛在网络编号管理”则可以有效解决这个问题。 目前,该系统已得到重庆市有关部门,以及国内外多家风投的关注,待进一步测试完善后,就将投入实际运用。 本文转自d1net(转载)

优秀的个人博客,低调大师

新一代大数据管家 DataSophon 1.2.0 正式发版

现在普遍认为是后Hadoop时代,CDH 的停更和闭源导致传统的 Hadoop 体系组件栈没有一个 称手好用的管理工具,越来越多新一代的大数据项目也在层出不穷, 同样也需要运维和管理,并且需要适配云原生的能力。不管技术如何演进都面临组件栈管理的问题,鉴于此 DataSophon作为 Datavane开源组织的推荐项目重磅开源。 DataSophon 是一个国产开源的大数据管理平台,在兼顾传统 Hadoop 组件的同时又支持新一代大数据组件栈,并且支持云原生的能力,致力于快速实现大数据组件部署、管理、监控以及自动化运维管理,旨在帮助用户快速构建稳定、高效、自愈、可弹性伸缩的大数据云原生平台。项目自开源以来,得到了很大关注,社区发展迅速,近日 DataSophon社区正式发布了 1.2.0 版本,带来了诸多改进和新功能的更新,具备更高的可用性和稳定性,欢迎大家下载使用。 Github:https://github.com/datavane/datasophon Gitee: https://gitee.com/datavane/datasophon 欢迎使用、关注、star、fork 新特性解读 1.2.0 版本,作为 DataSophon 开源之后发布的第一个版本,因此团队非常重视。在该版本全面支持了 Apache Doris,通过 DataSophon 可以便捷的部署、管理、监控 Doris。除此以外本次新增了初始化模块,可以自动完成集群环境初始化工作,避免因环境不一致导致集群安装失败的问题;还优化服务指令执行流程等... 该版本新增了诸多新功能、优化和修复了很多问题。 1. 全面支持 Apache Doris Apache Doris是基于 MPP 架构的新一代开源实时数据仓库,以极速易用的特点被人们所熟知, 在实时数仓和数据分析领域越发流行,本次 DataSophon 对 Doris 做了全面的支持,现在可在 DataSophon 上轻松的完成 Apache Doris 的集群部署和运维管理。 ​ 集群部署 在 Doris 集群部署方面,本次的新版本能够自动将 Apche Doris 的Follower、Observer、Be 等多种角色添加到集群中,全程界面化操作,动动鼠标即可完成,部署进度一目了然,大大省去了手动添加角色的麻烦,轻松实现集群的快速扩展和管理。 集群监控 对于 Apache Doris 集群的各项监控指标,也重点做了支持。您可以的在 DataSophon 中获得 Doris 集群的实时指标的各项信息,包括集群的节点数、详情、连接信息、运行状态和 CPU、JVM、内存、磁盘大小和 IO 的使用情况...。此外,您还可以查看集群的任务运行情况和其他详细信息,以便更好地了解集群的运行状况。 集群运维在集群运维方面 DataSophon 支持对 Doris 整个集群、FE、BE 节点进行启动、停止、重启等常规操作,同时支持了对DorisFE、BE 节点进行在线扩/缩容。可以很轻松的设置 Doris 的监控指标和告警,Apache Doris 各项参数也可以很方便的进行单个或批量设置,同时提供进入Doris 的原生WebUI 的入口,DataSophon 中 提供的各种丰富的运维操作可以极大的方便用户去运维管理 Doris。 2. 新增多个监控指标 本次新增了多个生产环境中普遍关心的运维指标,旨在满足大数据集群生产环境中的关键需求。这些运维指标的引入,使得用户能够更加有效地管理大数据集群,提高集群性能,降低故障率,从而实现高效运维。主要新增指标如下: HDFS 整个集群的客户端连接数。 NameNode 丢失的块数。 DataNode RPC 被调用次数。 DataNode RPC 队列积压长度。 DataNode RPC 平均处理时间。 ResouceManager RPC队列平均处理时间。 ResouceManager RPC 队列积压长度。 NodeManager Container 启动个数。 NodeManager Container 正在运行个数。 NodeManager Container 初始化中个数。 NodeManager 磁盘损坏个数。 3. 新增初始化模块 在集群部署过程中,都需要进行集群环境初始化,例如配置主机名、配置免密登录、安装离线 yum 源等初始化环境操作。DataSophon 通过 datasophon-init 模块自动初始化安装和配置所需的依赖项,省去手动安装和配置的繁琐步骤,从而大大提高部署效率,减少因集群环境不一致导致集群安装失败的风险。 同时为了方便运维人员操作和使用,系统不仅提供了友好的用户界面还提供了二次开发接口。通过自定义扩展二次开发,可以实现与不同类型的操作系统的兼容,满足不同用户的需求。这样一来,用户可以根据自己的实际情况进行灵活的配置和部署,提高了工作效率和准确性。 4. 其他改进和更新 1、升级 SpringBoot 版本为 2.6.1。 2、新增项目启动时自动创建数据表和初始化数据功能。 3、优化服务指令执行流程,避免出现服务指令进度卡死的情况。 4、优化 Hive 默认使用 Hive on YARN 环境配置。 5、新增集群删除功能。 6、修复不选择安装的服务实例时依然生成服务指令的问题。 7、修复租户管理中租户列表分页不生效的问题。 8、修复服务角色实例警告报警状态无法恢复的问题。 9、修复租户管理租户列表和用户组列表未按集群隔离的问题。 10、修复 Doris 安装部署时,未自动生成 Doris BE 数据目录的问题。 11、修复 HDFS 安装部署时出现找不到keystore 文件的问题。 12、 修复项目启动时出现的 "because it exists, maybe from xml file" 错误。 新官网上线 本次DataSophon上线了新官网,也完善了相关使用文档。在此感谢 Apache StreamPark 社区提供的技术支持,感谢 @songjianet、@haitaodesign 对官网的贡献。 感谢贡献者 DataSophon 开源社区的发展,离不开广大用户群体的积极反馈和宣传布道,更离不开贡献者们的无私贡献,感谢对此版本做出贡献的每一位贡献者。 致谢名单(排名不分先后): 88fantasy、a19920714liou、haitaodesign、WujieRen、thomasg19930417、AllDataDC、zhaoxiaoyi、liu-hai、gtk96、lnnlab、javaht、hzluting、zhzhenqin、liugddx、zq0757、chenss-1、zhu-mingye、zhangdw123、liuxin319、whybeyoung、hitozhu、green241、chyueyi、zhegemingzimeibanquan、songjianet 加入我们 DataSophon 项目自开源以来,得到了很大关注,社区发展迅速,越来越多的用户开始在生产环境部署使用 DataSophon,开发者也逐渐变多。如果 DataSophon 项目对您有帮助,请在 Gitee 或 Github 搜索 DataSophon 支持一下,点击 star 加关注。 我们时刻明白项目只有真正解决问题,给用户带来实际的价值才是立命之本,大力发展社区和贡献者才有出路,目前我们正在努力构建发展社区,我们坚信道阻且长,行则将至,竭诚欢迎广大的开发者和我们一起建设DataSophon 项目,共同推动项目的发展。 💻 项目地址: https://github.com/datavane/datasophon https://gitee.com/datavane/datasophon 🧐 提交问题和建议:https://github.com/datavane/datasophon/issues 🥁 贡献代码:https://github.com/datavane/datasophon/pulls 💁‍♀️官方文档:https://datasophon.github.io/datasophon-website 关于Datavane Datavane 是一个专注于大数据领域的开源组织(社区),由一群大数据领域优秀的开源项目作者共同创建,旨在帮助开源项目作者更好的建设项目、为大众提供高质量的开源软件,宗旨是:只为做一个好软件。目前已经聚集了一批优质的开源项目,涉及到数据集成、大数据组件管理、数据质量等。 在 Datavane 社区中,所有的项目都是开源开放、代码质量和架构设计优质的高潜力项目。社区保持开放中立、协作创造、坚持精品,鼓励所有的开发者、用户和贡献者积极参与我们的社区、共同合作,创新创造,建设一个更加强大的开源社区。 官 网:www.datavane.orgGithub:https://github.com/datavane

资源下载

更多资源
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册