问题解决

小伙伴们有没有遇到过这样一个场景，两台设施之间只能够通过一个通信软件进行通信。软件只能发送图片，其余格局的文件是被限度下载的。如上面所示： 在这种状况下，一些小伙伴可能会想用批改文件后缀名的形式，将文件后缀名改成 png、JPG 等格局。 有这种想法，对文件这个概念可能不太熟悉。 批改后缀名会批改文件的类型吗？文件名及后缀名与文件里的内容无关，在 windows 中，后缀名只辨别在你双击分件的时候，默认关上的形式。严格来说，文件是没有类型的。在没有与程序关联前，文件里的内容就是一串编码字符，独自的一个文件是没有意义的。 通常的，一个被具备特定意义地文件，会有一套与之对应地程序对该文件地进行解析，例如，office 中的一个程序可能对 doc、pdf 文件解析，视频播放器可能对MP4 等文件进行解析。 批改文件后缀名，文件里的内容并没有被扭转。将本应是 doc 内容的文件应用播放器程序进行关上，视频播放器不能辨认文件的内容，导致执行出错。 间接将文件后缀名批改成图片相干的后缀名( png 、jpg 等)行不通，是否能够将其余文件放到图片中呢？这个还真的能够。 先看一下图片的内容长什么样子，应用 notepad++ 开打图片文件： 图片文件有个特点是，在图片文件内容前面追加数据，如在 png 文件尾部 增加一些信息，再用图像工具关上该文件，是可能正确关上的。 因而能够将须要传输的文件追加到图片内容后。 当初我须要传输 context.zip 文件，能够将 content.zip 文件的内容，追加到carrier.png 文件后。 请不要间接将 zip 文件的内容，复制到粘贴板，再粘贴到 png 文件中！因为编码格局等问题，失去的内容不统一，最终导致操作失败。下图是间接从粘贴板复制粘贴过去的，能够看到内容曾经产生了变动。 正确的做法是，应用命令行的形式：# copy /b <file1> + <file2> <file3> 将file2 追加到file1前面，生成file3.# 图片要放在file1的地位$ copy /b carrier.png + content.zip oupt .png 能够看到这样复制过去的内容就是无误了，这样就能够将 zip 伪装成图片的模式传输过来了。 传输过来后，再将 output.png 中后面的内容删了，即是一个 zip 文件。（目前是 png 结尾，将 png 改成 zip 就默认以压缩工具关上 output.zip 了） ...

1.问题a形容：公司产品是基于虚机进行单机或者集群部署，须要革新成在rancher平台上容器化部署，各个服务注册到zk上应用的是容器零碎中的ip,注册到kong网关上应用的对应的主机ip加端口。在证书激活之前须要获取集群对应的sid信息，获取sid信息的接口十分慢，大概60s，而且屡次失败。 解决：获取sid十分慢，是因为生成sid会通过zk各个服务节点信息拜访各个服务节点，所以查找各个服务节点，批改对应服务pod的正本数，发现有一个不是生产环境服务，是对应服务的zk配置配置谬误，把对应的服务勾销注册到生产zk，获取失常。 2.问题b形容：用户登录之后会闪退 解决：查看登录页面申请的所有url,发现登录接口200胜利，到申请计量计费服务时候报401谬误，确认token信息是有携带的，应用postman调用也是401谬误，也就是说token信息有问题，但申请别的服务是没有问题的，咱们是应用redis做token共享的，也就是计量计费的redis不能失常获取token信息，那么可能是计量计费服务redis配置谬误，要么是redis集群有问题，但只有计量计费服务有问题，应该是配置有问题，运维共事查看配置，的确是配置错了。

作者 | 张晓宇（衷源） 阿里云容器平台技术专家 关注『阿里巴巴云原生』公众号，回复关键词“1010”，可获取本文 PPT。 导读：资源利用率一直是很多平台管理和研发人员关心的话题。本文作者通过阿里巴巴容器平台团队在这一领域的工作实践，整理出了一套资源利用提升的方案，希望能够带给大家带来一些讨论和思考。 引言 不知道大家有没有过这样的经历：当我们拥有了一套 Kubernetes 集群，然后开始部署应用的时候，我们应该给容器分配多少资源呢？ 这很难说。由于 Kubernetes 自己的机制，我们可以理解容器的资源实质上是一个静态的配置。 如果我发现资源不足，为了分配给容器更多资源，我们需要重建 Pod； 如果分配冗余的资源，那么我们的 worker node 节点似乎又部署不了多少容器。 试问，我们能做到容器资源的按需分配吗？接下来，我们将在本次分享中和大家一起进行探讨这个问题的答案。 生产环境中的真实挑战 首先请允许我们根据我们的实际情况抛出我们实际生产环境的挑战。或许大家还记得 2018 年的天猫双 11，这一天的总成交额达到了 2135 亿。由此一斑可窥全豹，能够支撑如此庞大规模的交易量背后的系统，其应用种类和数量应该是怎样的一种规模。 在这种规模下，我们常常听到的容器调度，如：容器编排，负载均衡，集群扩缩容，集群升级，应用发布，应用灰度等等这些词，在被“超大规模集群”这个词修饰后，都不再是件容易处理的事情。规模本身也就是我们最大的挑战。如何运营和管理好这么一个庞大的系统，并遵循业界 dev-ops 宣传的那样效果，犹如让大象去跳舞。但是马老师曾说过，大象就该干大象该干的事情，为什么要去跳舞呢。 Kubernetes 的帮助 大象是否可以跳舞，带着这个问题，我们需要从淘宝、天猫等 APP 背后系统说起。 这套互联网系统应用部署大致可分为三个阶段，传统部署，虚拟机部署和容器部署。相比于传统部署，虚拟机部署有了更好的隔离性和安全性，但是在性能上不可避免的产生了大量损耗。而容器部署又在虚拟机部署实现隔离和安全的背景下，提出了更轻量化的解决方案。我们的系统也是沿着这么一条主航道上运行的。假设底层系统好比一艘巨轮，面对巨量的集装箱---容器，我们需要一个优秀的船长，对它们进行调度编排，让系统这艘大船可以避开层层险阻，操作难度降低，且具备更多灵活性，最终达成航行的目的。 理想与现实 在开始之初，想到容器化和 Kubernetes 的各种美好场景，我们理想中的容器编排效果应该是这样的： 从容：我们的工程师更加从容的面对复杂的挑战，不再眉头紧锁而是更多笑容和自信； 优雅：每一次线上变更操作都可以像品着红酒一样气定神闲，优雅地按下执行的回车键； 有序：从开发到测试，再到灰度发布，一气呵成，行云流水； 稳定：系统健壮性良好，任尔东西南北风，我们系统岿然不动。全年系统可用性 N 多个 9； 高效：节约出更多人力，实现“快乐工作，认真生活”。 然而理想很丰满，现实很骨感。迎接我们的却是杂乱和形态各异的窘迫。 杂乱，是因为作为一个异军突起的新型技术栈，很多配套工具和工作流的建设处于初级阶段。Demo 版本中运行良好的工具，在真实场景下大规模铺开，各种隐藏的问题就会暴露无遗，层出不穷。从开发到运维，所有的工作人员都在各种被动地疲于奔命。另外，“大规模铺开”还意味着，要直接面对形态各异的生产环境：异构配置的机器、复杂的需求，甚至是适配用户的既往的使用习惯等等。 除了让人心力交瘁的混乱，系统还面临着应用容器的各种崩溃问题：内存不足导致的 OOM，CPU quota 分配太少，导致进程被 throttle，还有带宽不足，响应时延大幅上升...甚至是交易量在面对访问高峰时候由于系统不给力导致的断崖式下跌等等。这些都使我们在大规模商用 Kubernetes 场景中积累非常多的经验。 直面问题 稳定性 问题总要进行面对的。正如某位高人说过：如果感觉哪里不太对，那么肯定有些地方出问题了。于是我们就要剖析，问题究竟出在哪里。针对于内存的 OOM，CPU 资源被 throttle，我们可以推断我们给与容器分配的初始资源不足。 ...

作者：杨弢（搏远） Flink 支持 Standalone 独立部署和 YARN、Kubernetes、Mesos 等集群部署模式，其中 YARN 集群部署模式在国内的应用越来越广泛。Flink 社区将推出 Flink on YARN 应用解读系列文章，分为上、下两篇。上篇分享了基于 FLIP-6 重构后的资源调度模型介绍 Flink on YARN 应用启动全流程，本文将根据社区大群反馈，解答客户端和 Flink Cluster 的常见问题，分享相关问题的排查思路。 客户端常见问题与排查思路▼ 应用提交控制台异常信息：Could not build the program from JAR file. 这个问题的迷惑性较大，很多时候并非指定运行的 JAR 文件问题，而是提交过程中发生了异常，需要根据日志信息进一步排查。最常见原因是未将依赖的 Hadoop JAR 文件加到 CLASSPATH，找不到依赖类（例如：ClassNotFoundException: org.apache.hadoop.yarn.exceptions.YarnException）导致加载客户端入口类（FlinkYarnSessionCli)失败。 **▼ Flink on YARN 应用提交时如何关联到指定 YARN 集群？** Flink on YARN 客户端通常需配置 HADOOP_CONF_DIR 和 HADOOP_CLASSPATH 两个环境变量来让客户端能加载到 Hadoop 配置和依赖 JAR 文件。示例（已有环境变量 HADOOP_HOME 指定 Hadoop 部署目录）： export HADOOP_CONF_DIR=${HADOOP_HOME}/etc/hadoopexport HADOOP_CLASSPATH=${HADOOP_HOME}/bin/hadoop classpath▼ 客户端日志在哪里，如何配置？ ...

前言作为阿里云底层提供的基础设施，内部的物理网络和许多网络产品在数据平面给客户的可操作性并不高，从一定程度上来说是个黑盒。当然，在传统的IDC环境，业务和物理网络之间也存在同样的隔阂。所以在遇到业务卡顿、延迟、不通等问题的时候，很容易怀疑到网络。因此如何抽丝拨茧，找到正确的方向对症下药才能够真正的解决问题。毕竟“真相只有一个”。 在进行问题排查和处理的时候，难度最高的场景就是极度偶发，复现频率极低的问题。尤其在网络排查的领域，通常为了性能和控制资源消耗，不会将每一个数据包的情况都一一记录下来，对于一次偶发的应用层记录的超时，网络层通常没有明确的对应此次应用层调用的包交互记录，因此排查起来非常困难。 在这次的案例中，我们通过一个客户端查询redis集群偶发超时的小案例，来说明一些诊断思路、排查手段，进而引出一些在网络方面提高业务稳定性的最佳实践。 问题环境这次的问题是一个交互性web应用中的一个子模块，主要进行redis查询，可以简单将其理解为视频弹幕网站中“查询弹幕”的小模块。这个模块的拓扑非常简单： 在上面的拓扑中，客户使用ECS构建了一个Redis集群，前面用Codis实现了一层Redis Proxy （为了通用性，后面均用Redis proxy来描述），并将这组Redis proxy挂载在一个SLB后，通过SLB的单一入口提供服务。 问题现象客户的主要问题是访问其自建Redis系统的客户端会不定期出现超时报错，尽管总体概率不高，但是报错概率高于其业务运行在原有机房的水平。超时报错主要有两种情况： 一般情况下超时数量与业务量呈正相关，非业务高峰期但是SLB、ECS的资源使用率均较低。会存在突发性的大量超时。诊断思路作为问题排查的第一步，首先要了解到问题本身所处的上下文和环境。在平时诊断问题收集信息的时候，为了有条理的、全面的收集信息，笔者将需要收集的信息分为两种类型：资源因素和环境因素。 资源因素：即发生问题的系统的拓扑。比如涉及的各种应用程序、主机、转发设备、链路资源等，并且要充分理解这些资源组建在拓扑中起到的作用。环境因素：即描述这个问题所需要的信息，比如报错日志，问题发生时间、频率，应用层设置的超时时间等等。了解资源因素和环境因素后，可以将问题的定义明确为：在哪些资源上发生了什么样的问题，然后根据该定义收集与问题相关的信息，并在解读和分析的时候通过数据排除所有的不可能，这样才能进行高效和准确的问题排查。 在本案例中，资源因素已经在上文的拓扑中阐述，问题所涉及的环境因素包括：客户设置的是50ms超时，在客户端的报错是read timeout（代表排除了tcp的三次握手超时），报错频率为非业务高峰期一个小时10个左右，业务高峰期1小时上百个。但是偶尔（一周内偶尔发生一次到两次）无论业务高峰还是非业务高峰都会有较多的，上百次的read timeout和connect timeout。客户已经排查过redis，其查询时间每次耗时不超过10ms，而redis proxy没有记录转发的日志。 排查方法因为所有可用的日志仅能定位到这个系统的两端（客户端、Redis），需要收集进一步的信息。面对这种超时类的问题，最直接、有效的办法就是进行抓包。而该问题发生的频率不高，整个系统流量也比较大，一直开着抓包很容易将磁盘撑满，因此需要使用循环抓包： tcpdump -i <接口|any> -C <每文件大小> -W <文件个数> -w <保存文件名> 抓包过滤条件该命令的意思是针对某个接口，按照过滤条件进行抓包，保存指定文件名前缀的文件下，最多占用每文件大小*文件个数 的磁盘空间并循环覆盖。开启循环抓包后，等待客户端报错再次出现，即可抓到现场的包交互过程。 抓包的结果文件可以使用wireshark打开，但是使用循环抓包抓到的数据包文件较大、数量较多，可以使用下面的小技巧进行快速的过滤： //在安装了wireshark的电脑上都会有capinfos和tshark两个命令，以笔者使用的macOS为例~$ capinfos -a -e *cap //使用capinfos查看抓包文件的其实时间和结束时间，选取包含报错时间+-超时时间的文件，其他文件就不需要了File name: colasoft_packets.capPacket size limit: inferred: 66 bytes - 1518 bytes (range)First packet time: 2019-06-12 09:00:00.005519934Last packet time: 2019-06-12 09:59:59.998942048File name: colasoft_packets1.capPacket size limit: inferred: 60 bytes - 1518 bytes (range)First packet time: 2019-06-12 09:00:00.003709451Last packet time: 2019-06-12 09:59:59.983532957//如果依然有较多文件，则可以使用tshark命令进行筛选。比如报错中提到Redis查询一个key超时，则可以用以下脚本找到这次查询请求具体在哪个文件中：~$ for f in ./*; do echo $f; tshark -r $f 'tcp.payload contains "keyname"'; done找到对应的请求之后，再用wireshark打开该文件，找到对应数据包，跟踪对应流来找到五元组和整个流的上下文交互。 ...