博客

  • FileDetector 文件监控 日志监控

    FileDetector最初是用来监测日志文件变化的,有变化就进行邮件通知。此软件的设计主要体现在配置文件上了。所以,从配置看软件内部逻辑设计:
    app.json

    {

        “DefaultDetectorCinfig”: “defaultDetector.json”,

        “RecentOpTime”: “2016-09-22T18:27:50.0995478+08:00”,

        “IsDailyResetFileStamp”: true

    }
    defaultDetector.json

    {

        “FileTargetPattenList”: [

            “Log/*.txt”,”Log2/*.txt”

        ],

        “FileStampList”: {

            “Log/1.txt”: “C4CA4238A0B923820DCC509A6F75849B”,

            “Log/2.txt”: “C81E728D9D4C2F636F067F89CC14862C”,

            “Log\\2016-09-22-001.txt”: “47BCE5C74F589F4867DBD57E9CA9F808”,

            “Log\\2016-09-22.txt”: “7FC81F243BF93E98FA624038EAE58322”

        }

    }
    分步讲解:
    由于此软件为控制台模式的,没有操作界面,用cmd调用,也利用在服务器上进行运行。
    设计这个app.json的大概思路:
    DefaultDetectorCinfig:默认监测节点主要是为了方便运行调试
    RecentOpTime:记录最近检测时间,由于日志文件每天滚动,因此隔天的文件戳要清空(FileStampList)
    IsDailyResetFileStamp:这个是隔天清空的开关,对于非日志文件,不用清空,这个开关就关掉。
    设计defaultDetector.json的思路:
    FileTargetPattenList:需要检测的目标文件,这里采用的是Pattern,可以匹配多个文件,并且支持多处文件夹的文件。
    FileStampList:不为空的文件戳都存放在此,监测变化的时候比较文件戳即可。这里采用了md5抽取文件戳。
    最佳使用实践:
    针对每天都会生成yyyy-MM-dd的文件,配置一个FileDetector实例,传入配置参数,比如:FileDetector.exe logfileDetector.json
    针对不变化的文件,配置一个FileDetector实例,传入配置参数,形如:FileDetector.exe staticFileDetector.json
    取名记
    每次写个小工具,都要花点时间想名字,本来想用FileWatcher,但是还是选了一个FileDetector。Watcher感觉像手表,嘻嘻,天天说去W,也比较污。
    扩展使用
    写这个主要是用来做日志监控的,但是本身用来做网站文件监测也是不错的。自己文件用这个监测一下,也可以知道有没有被“黑”。
    话说为了提供跨境商品服务,也是豁出去了。这些监测都是及时监测跨境业务流程中的服务状态。
    有需要跨境商品的亲,记得联系哟。 QQ:1132958967

  • C#/.Net 动态编译 UnitedAPI提速器

    关键词:CSharpCodeProvider、ICodeCompiler、CompilerParameters、CompilerResults、Assembly

    前言:

    —————————–

    1.为UnitedAPI进一步提升速度,一个要从纯SQL转存储过程,这个好实现。另一个就要利用动态编译特性,将原本动态的东东静态化,即用享受动态的灵活性,也不失静态的效率。

    2.在一段逻辑流中增加一段新的控制逻辑,就没有必要打开vs了,直接web中增加,然后实时编译。这个可以为UnitedAPI提供更丰富而实时的控制能力。

    3.可以用开vs了,直接弄个在线编程工具,在线编程。断点调试肿么破?感觉也可以弄个动态编译自动扫描每一行代码的情况,然后模拟出断点~~

     

    转载内容:

    ——————————————————————

    一、CSharpCodeProvider
        提供对C#代码生成器和代码编译器的实例的访问。如果要动态生成VB代码,可以使用VBCodeProvider。
    CreateCompiler():获取编译器的实例。
    二、ICodeCompiler
        定义用于调用源代码编译的接口或使用指定编译器的CodeDOM树。每种编译方法都接受指示编译器的CompilerParameters对象,并返回指示编译结果的CompilerResults对象。
    CompilerAssemblyFromSource(CompilerParameters option, string source):使用指定的编译器,从包含源代码的字符串设置编译程序集。
    三、CompilerParameters
    表示用于调用编译器的参数。
    ReferencedAssemblies:获取当前项目所引用的程序集。Add方法为程序集添加引用。
    GenerateExecutable:获取或设置一个值,该值指示是否生成可执行文件。若此属性为false,则生成DLL,默认是false。
    GenerateInMemory:获取或设置一个值,该值指示是否在内存中生成输出。
    四、CompilerResults
        表示从编译器返回的编译结果。
    CompiledAssembly:获取或设置以编译的程序集,Assembly类型。
    五、Assembly
        就是程序集了(不知道如何描述了)。

    转载自:http://www.cnblogs.com/jailu/archive/2007/07/22/827058.html

  • .在创建用户定义表类型定义后不能对其进行修改。(没搞懂为什么不可以修改)

    UserDefinedTableType  用户自定义表类型
    我想增加一个报检号,发现这个自定表类型无法修改,坑坏了~~
    各种找资料没有alter的影子!
    只好依据提示先将引用的存储过程del掉,再将 自定表类型 del掉,再创建一个包含报检号的
    一坑一世界 这要是 用户自定义表类型用的地方多一点,就让人抓狂了

    如何进行全自动修改呢?  其实是可以实现的,

    用户定义表类型的修改方案ABC

    方案一:依据报错提示,使用正则提取要临时del的存储过程等,调整完之后再将原删除的存储过程刷进去。

    方案二:将所有的数据库对象导出sql脚本,进行引用分析,将引用过的临时删除

    汗,就是这么绕~

  • Excel to SQL

    依据Excel与sql模板,生成sql语句,算是解决了繁琐的手工操作。
    小工具使用了第三方库:
    EPPlus.4.1.0
    Newtonsoft.Json.9.0.1

    sql模板可以自主定制,非常灵活~

    image

    刚写完,自己用了用~正好同事在被Excel导入所虐,也给推销出去了~~

  • WebConsole/Web Cmd/Cmd behind

    image

    通过网页远程执行cmd命令,实现数据重置、数据推送执行,方便小伙伴进行联调。

    小工具主要是通过调用cmd命令并将执行结果返回到Web页面。

    返回结果示例:

    Microsoft Windows [版本 10.0.10586]
    (c) 2015 Microsoft Corporation。保留所有权利。
    
    c:\windows\system32\inetsrv>cd C:\Users\*\5.软件与工具\跨系统数据同步工具\DataPusher\DataPusher\DataPusher\bin\Debug\
    
    C:\Users\zhong\Documents\*\5.软件与工具\跨系统数据同步工具\DataPusher\DataPusher\DataPusher\bin\Debug>copy ResetConfig\*  Config /Y
    ResetConfig\app.json
    ResetConfig\CIQStatus.json
    ResetConfig\default.json
    ResetConfig\PurchaseHistory.json
    ResetConfig\PurchaseNewStatus.json
    已复制         5 个文件。
    
    C:\Users\zhong\Documents\*\5.软件与工具\跨系统数据同步工具\DataPusher\DataPusher\DataPusher\bin\Debug>exit
  • OpenStack如何支持大规模PaaS平台实现快速开发和部署?

    image

    “OpenStack是一个真正实现快速开发和交付的赋能器。”瑞士电信公司PaaS首席架构师Marcel Härry说。

    瑞士电信公司以OpenStack为基础创建了一个大型的生产级行业标准PaaS(平台即服务)平台。他们的解决方案聚焦在为全球客户提供一个企业级PaaS环境,同时为客户提供基于Cloud Foundry和OpenStack的多种交付模式。作为瑞士主要的电信提供商,瑞士电信很早就与红帽、Cloud Foundry和PLUMgrid等公司展开合作,开启了自己的OpenStack之旅。

    近日,OpenStack.org的Superuser频道采访了瑞士电信PaaS首席架构师、兼Cloud Foundry基金会技术咨询委员会成员Marcel Härry。以下是此次访谈的详情。

    瑞士电信是如何使用OpenStack的?

    OpenStack允许我们快速开发和部署基于Cloud Foundry的PaaS解决方案,以及快速在SDN和容器内开发出新的功能。OpenStack是一个真正实现快速开发和交付的赋能器。

    比方说,我们的PaaS解决方案是以不同网站上的多个OpenStack安装为基础的。从开始设置和安装仅过去了半年时间,我们就已经交付了两个PaaS解决方案的生产实例。目前我们正在为知名客户运行多个生产级部署,未来这些客户还将使用我们的平台开发自己的SaaS解决方案。此外,我们还在为众多实验室和开发实例提供基础设施。这些环境允许我们在保持快速创新步伐期间强化和稳定新的功能,同时确保我们拥有一个稳定的大环境。

    我们正在运行大量OpenStack堆栈,这些堆栈在设计时就被限定在一个单独地区和一个唯一的可用域内。其规模从多个计算节点到数十个计算节点不等,并且可以根据特殊工作负载的需求进行扩展。我们的目的不是创建一个庞大的部署,而是创建多个规模较小的堆栈,从而托管那些能够在不同环境之间进行迁移的工作负载。这些堆栈正托管着数以千计的虚拟机,而它们正在托管着数以万计的容器,以为我们的客户运行生产应用或服务实例。

    目前正在OpenStack上运行着哪些类型的应用或工作负载?

    我们目前使用OpenStack作为我们的基础设施编排器大约已经有三年时间了。瑞士电信已经在OpenStack上创建了自己的弹性云。以此为基础,我们正在运行着瑞士电信的Application Cloud或者是PaaS。它们是以Cloud Foundry为基础的,同时将PLUMgrid作为了SDN层。瑞士电信的云为IT架构师提供了IaaS,为终端用户提供了SaaS,为开发者提供了PaaS,以及其他的一些服务和应用。我们主要是在OpenStack上运行我们的PaaS/Cloud Foundry环境,以及那些运行在Docker容器中的相互关联的托管服务(例如DBaaS、Message Service aaS)。

    关于OpenStack,瑞士电信正面临着如些挑战,你们又是如何克服它们的?

    OpenStack的学习曲线属于急剧上升型。在我们开始学习OpenStack的三年之前,几乎没有什么可以参考的架构,特别是在许多层面上无法满足企业级的需求,例如双站点、高可用性(HA)等。此外,我们直接进入到了SDN、SDS部署层面,这些部署的规模都非常大,但是最终却取得了成功。

    在OpenStack实践的道路上,重要的里程碑是什么?

    瑞士电信首个测试环境上线的时间是在2014年春季,内部开发环境上线时间是2015年春季。完全托管在OpenStack上的Cloud Foundry公共环境在2015年秋季上线。在我们的堆栈上,来自金融和工业等多个公司的企业级和关键业务工作负载上线日期是2016年春季。瑞士电信近期宣布,瑞士再保险公司已经成为了其首批的大型企业云客户之一。

    使用OpenStack之后,瑞士电信所收获到的最大好处是什么?

    可插入性和多厂商的互操作性(例如与PLUMgrid 等SDN和与ScaleIO等SDS)避免了厂商锁定,同时创建了一个无缝系统。OpenStack让瑞士电信能够验证使用DevOps模式与环境的部署,从而加快了部署和开发应用速度。它们可以简化从PoC至生产环境的步骤,让我们能够更轻松地扩展使用分布式集群架构的服务。

    你对那些考虑转向OpenStack的公司有何建议?

    虽然在开始时会遭到困难,但是这是值得的。要精心选择合作伙伴和厂商,这将帮助我们在很短时间内上线。考虑推动企业内部转向DevOps模式,为首次部署做好准备,这能够让我们在需要时,让企业针对工作负载改变部署模式(例如转向云原生模式等)。

    你是如何加入OpenStack社区的?

    今年的奥斯汀峰会是我们第二次参加OpenStack Summit。这个峰会为我们提供了一个审视自身部署和架构,以最佳实践和现实世界的生产级应用案例回馈社区的机会。此外,我们还可以为众多OpenStack项目直接贡献补丁和提升方案。这些补丁中的一部分已经被接受,部分正在准备中,为发布进行进一步完善。此外,我们正在密切地与我们的厂商,红帽、EMC、ClusterHQ/Flocker、PLUMgrid和Cloud Foundry基金会展开合作。

    同时,我们还在OpenStack项目中,针对它们的集成性和稳定性,与供应商们展开进一步合作。例如,我们与Flocker针对他们基于Cinder的驱动器密切合作,以在容器中展开持续编排。同时,我们还通过我们的供应商提交了许多漏洞报告,与他们合作解决这些问题,这些问题同样会被反馈到OpenStack社区。

    下一步的计划?

    我们为客户提供了一个针对非持续性容器工作负载的完美解决方案。我们正在不断地发展这一产品,在它们在进入OpenStack基础设施编排时努力满足企业和金融垂直市场的实际需求。

    编者注:本文编译自superuser.openstack.org,编译者Frank Chan。

    转自:https://www.ustack.com/news/how-openstack-public-cloud-cloud-foundry-a-winning-platform-for-telecoms/